Virtual extension methods -- a strawman design

Florian Weimer fweimer at bfk.de
Tue May 25 05:40:53 PDT 2010


* Brian Goetz:

> The attached document reflects our current thinking in the area of
> extension methods, which was introduced in section 8 of the Strawman
> proposal.  This document (arguably) improves on the static extension
> method scheme presented there.

The document is written in a way that gives the impression that
extension methods are to be used by the JDK 7 platform authors only.
Is this really your intent?

The reason I'm wondering is the final sentence in the first paragraph
of section 4 ("The class file emitted by the compiler implements all
methods in the interface...") and the first sentence in section 5
("Classes compiled by the JDK 7 compiler will not need any special
treatment").  This is just not true if the feature (that is,
binary-compatible evolution of interfaces) is available to the general
public.

Are there any constraints on the visibility of the default method?
The obviously loophole-free approach would be to require that they are
public methods in the same package as the interface itself.  If you
permit non-public methods here (or public methods in other packages),
you need to make sure that class authors are aware of the ability to
reference overridden methods way above in the class hierarchy, which
might be used to bypass security checks.

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99


More information about the lambda-dev mailing list