Some pullbacks

[Brian Goetz]

> 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.