Some pullbacks

[Stephen Colebourne]

These features will be missed, but are not essential, unlike static
methods on interfaces.

An issue that I felt was related to these features was the coding
standard for methods on interfaces. Specifically, should methods
declare "public" or not.

My preference is that the JLS and OpenJDK should change to always use
"public" for methods on interfaces. This is because (a) default
methods on interfaces look very odd without the "public" modifier, and
(b) an interface of mixed abstract and default methods looks very odd
with some declared "public" and some not.

I also believe that declaring public will put codebases in a better
position for the future addition or the "package" modifier and
"private" methods on interfaces.

Stephen


On 29 January 2013 16:06, 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.
>
> 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.)
>