Draft JEP: Incubating Language and VM Features

Volker Simonis volker.simonis at gmail.com
Fri Jan 26 10:25:56 UTC 2018


Hi Alex,

after reasoning more about this proposal I came to the conclusion that
we actually already have a mechanism in place for exactly this use
case. It is called JSR (Java Specification Request) [0] and it is part
of the JCP process.

Numerous Java technologies have been developed as JSRs in the past.
Examples are Generics (JSR 14), InvokeDynamic (JSR 292) and JVMTI (JSR
163) to name just a few, but you can also take a look at [1] for a
complete list.

- JSRs can be developed independently of Java SE releases
- JSRs have an associated TCK
- JSRs can be easily developed independently by different vendors
- JSRs can be maintained and evolved
- JSRs can be included into an umbrella Java SE platform JSR

This all seems like a perfect fit for the use case that's being tried
to be addressed with the proposed "Incubating Language and VM
Features" JEP, however with the following additional advantages:

- we don't "pollute" the SE specification with features which may be
potentially changed in an incompatible way and/or removed every six
month.
- every Java vendor has the possibility to freely decide which JSR he
wants to support (until the JSR get's merged into the SE specification
of coarse)
- the JSRs are independent of the Java SE release (instead of the
proposed '--incubating' we could use something like
'--with-jsr=<jsr_nr>')

If Oracle doesn't like the JSR process, it can easily change and/or
improve it. Oracle is actually the only entity who can do that! If
Oracle thinks that the JSR/JCP process is broken beyond repair, it
could easily donate the whole Java SE reference implementation and TCK
to an independent organization as it already happened recently with
Java EE. That organization could then develop further Java releases in
the way envisioned by the proposed JEP.

The "Incubator Modules" process introduced with JEP 11 [2] is an
OpenJDK-only process which is fine. OpenJDK can arrange its
development processes in any way it likes. But this proposal touches
the way how the Java SE specification is created and maintained and in
my opinion that's the mission of the JCP.

Regards,
Volker

[0] https://www.jcp.org/en/jsr/overview
[1] https://www.jcp.org/en/jsr/platform?listBy=2&listByType=platform
[2] http://openjdk.java.net/jeps/11


On Fri, Jan 19, 2018 at 8:52 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
> Many of you are familiar with Incubator Modules from JEP 11. They let us
> ship "incubating" APIs in mainline JDK releases so that we can gather
> feedback from the largest possible pool of developers.
>
> We've been thinking about the idea of having "incubating" features in the
> Java language and the JVM, again with the aim of maximizing feedback. To be
> clear, these would be full-fledged features of the Java SE Platform, in
> contrast to the JDK-specific nature of incubating APIs.
>
> The draft JEP below explains our thinking. Like JEP 11, it's an
> Informational JEP rather than a Feature JEP because it outlines
> policy/principles rather than a concrete feature. Your comments are welcome.
>
>   https://bugs.openjdk.java.net/browse/JDK-8195734
>
> Alex


More information about the jdk-dev mailing list