Virtual extension methods -- a strawman design
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
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