Some pullbacks

[Remi Forax]

On 01/29/2013 05:06 PM, Brian Goetz wrote:
> We would like to pull back two small features from the JSR-335 feature 
> plan:
>
>  - private methods in interfaces
>  - "package modifier" for package-private visibility
>
> The primary reason is resourcing; cutting some small and inessential 
> features made room for deeper work on more important things like type 
> inference (on which we've made some big improvements lately!)  Private 
> methods are also an incomplete feature; we'd like the full set of 
> visibilities, and limiting to public/private was already a compromise 
> based on what we thought we could get done in the timeframe we had.  
> But it would still be a rough edge that protected/package were missing.
>
> The second feature, while trivial (though nothing is really trivial), 
> loses a lot of justification without at least a move towards the full 
> set of accessibilities.  As it stands, it is pretty far afield of 
> lambda, nothing else depends on it, and not doing it now does not 
> preclude doing it later.  (The only remaining connection to lambda is 
> accelerating the death of the phrase "default visibility" to avoid 
> confusion with default methods.)
>

The package modifier is only needed if we introduce method with package 
visibility in interface,
we don't allow that so it doesn't pull its own weight.

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

Rémi