brian.goetz at oracle.com
Wed Jan 30 11:51:17 PST 2013
> For private methods in interfaces, I have two fears, the first one, we
> don't provide a good answer if users want to share code between
> different default methods.
Yes, this was the motivation for the feature in the first place. We're
all in agreement (I think) that this is desirable. As a library writer,
I want the full set of accessibilities for interface methods, and
private methods would have been a good start.
> The second one is that having a feature which
> is present in the VM but not accessible in Java often leads to bugs
> because the feature is not enough tested (it's harder to write tests if
> you have no way to express it in Java).
> Brian seams well aware of these trade-offs so I will trust Brian on this.
Yes, having a VM feature that has no corresponding language surfacing
does complicate testing. However, this is a regular state of affairs
for our VM team; the VM has to deal with all sorts of horrible
classfiles which could never come out of javac, or could only come out
of javac as a result of tortured separate compilation (such as dealing
with the case when a private method overrides a public one and is then
overridden by a public method which makes a super call (correct
behavior: super-call inherits "around" the private method, blech.))
Javac would never produce this classfile -- and that's not a bug -- but
the VM still has to expect that situation.
More information about the lambda-spec-experts