daniel.smith at oracle.com
Tue Jan 29 08:19:17 PST 2013
On Jan 29, 2013, at 9:06 AM, Brian Goetz <brian.goetz at oracle.com> 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.
To clarify (because I find a lot of people get mixed up about this): while there will be no language support for private methods in interfaces, there _will_ be VM support for private methods in interfaces. This is useful for some compiler tricks that lift things into the top level; thanks to default methods, the top level may now be an interface. There will be no VM support for package-/protected-access methods in interfaces. (This is all consistent with the 0.6.1 spec.)
> 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.)
I'll be changing the 0.6.1 spec to remove the 'package' syntax but keep the "package access" terminology.
More information about the lambda-spec-experts