Varied interface method visibility (was Final defenders)
talden at gmail.com
Wed Aug 8 14:06:00 PDT 2012
On Thu, Aug 9, 2012 at 2:53 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
>> Could reintroducing the 'package' keyword as an access-specifier be
> Yes, this is already being explored.
> However, let me set some realistic expectations -- language / VM features have a long lead time, even trivial-seeming ones like this. The time for proposing new language feature ideas for Java SE 8 has pretty much passed.
I'm under no illusion that this is trivial. And what's more, being
somewhat orthoganal to the other JDK8 features, it should almost
certainly be a JDK9 issue. Ideally of course we'd start the
discussions of post JDK8 now as well to have a backlog well developed
so that JDK9 can be a much much shorter release cycle...
An interesting experiment that Oracle is going to experience
firsthand, is whether we either start to see JDK release fragmentation
of the community (and crucially perhaps, some of the commonly used
libraries) as the release cycle speeds up or whether the community
moves to a defacto Tick-Tock model of skipping the occasional release,
leaving adoption of those releases to the projects that have a
critical driver tied to their new feature set.
I understand that JDK9 is already pegged at 24 months following JDK8
which is perhaps unfortunate for both java and JDK8. There are big
items in JDK9 (jigsaw for one) and 24 months might be short enough to
encourage projects to delay JDK migration until JDK9 is settled in. A
shorter cycle _might_ be better if it lets the early adopters help
settle the new features in (affecting libraries, educational material,
community-member skill-sets) whilst allowing selective migration for
projects (though that fragmentation problem is a potentially large one
for JDK language and JVM features).
Regardless of how the work is slotted into the release cycle, I glad
the feature is being reviewed. We could certainly simplify some
internal designs if we were able to use interfaces that don't leak
implementation into our public API.
More information about the lambda-dev