JEP 11: Incubator Modules
mark.reinhold at oracle.com
mark.reinhold at oracle.com
Tue Dec 6 16:28:35 UTC 2016
2016/12/6 7:28:17 -0800, volker.simonis at gmail.com:
> On Fri, Dec 2, 2016 at 6:20 PM, <mark.reinhold at oracle.com> wrote:
>> New JEP Candidate: http://openjdk.java.net/jeps/11
> I have some questions regarding this JEP:
> 1. First of all, I couldn't find any discussions around this JEP on
> any of the OpenJDK mailing lists I'm subscribed to (and I'm subscribed
> to quite a few of them :) Maybe just I have missed it, but according
> to the JEP 2.0 process  I thought that there should be a discussion
> and evaluation before the OpenJDK lead changes a JEP to "Candidate"
> status and adds it to the JDK Roadmap.
This is an Informational JEP, not a Feature JEP. As such the notion
of "Candidate" isn't really apt, and in fact the JEP process specifies
a different workflow for Informational JEPs, but because JIRA is so
fiendishly difficult to configure we haven't implemented that workflow
in JBS, so we make do with the workflow that we have.
Informational JEPs aren't meant to be targeted to specific releases, so
I've removed the "9" target from JEP 11.
> 2. This JEP is targeted for Java 9 but we're already close to "Feature
> Extension Complete". I understand that this JEP itself probably
> doesn't require a lot of implementation work. Maybe there's no
> implementation effort at all, but that's not totally clear to me from
> the JEP.
The minor mechanisms needed to support JEP 11 are part of the module
system, JEP 261, and will be described in a forthcoming update to that
> That said, do you plan to add new "Incubator Modules" to jdk9
> before "Feature Extension Complete" or will there be different (more
> relaxed) rules for integrating incubator modules into jdk9? E.g. the
> owner of "JEP 110: HTTP/2 Client"  stated on the mailing list that
> he's planning to integrate that JEP (which is not complete to my
> understanding" as incubator module into jdk9.
Yes, the plan is to integrate JEP 110 as an incubator module. We also
plan to refactor the `jlink` tool's experimental plug-in API (JEP 282)
into its own incubator module. I'm not aware of any other plans for
incubator modules in JDK 9.
> 3. In section "Relationship to other modules" the JEP mentions that
> "in exceptional cases, it may be acceptable for standard and
> non-incubator JDK-specific modules to specify requires dependences
> upon incubator modules". I wonder how this plays together with Java
> standardization and the JCP process. How can you standardize a Java
> release in a JSR if there exist dependencies on a non-standardized
> "incubator module"?
You can, but only if the incubator module is merely part of the standard
module's implementation, so that its types aren't exposed anywhere in
the standard module's API. That's why JEP 11 mentions the use of
`requires` directives here rather than `requires transitive`.
> 4. In section "Integration points" the JEP mentions that "low-level
> operations can be exposed through qualified exports from the
> appropriate module(s) in the JDK build to the incubator module
> containing the feature". I'm still not a module expert, but I wonder
> if the set of exports from a standard module isn't defined by the Java
The set of unqualified exports from a standard module will be part of
the Java SE Platform specification. Qualified exports from one module
to another within the JDK, whether those modules are standard or not,
are invisible to all other modules and hence not part of the SE
> Are others allowed to use this mechanism for exposing
> internals of standard modules trough their own incubator modules?
> 5. Will the "jdk.incubator" package and module name be special or
> protected in some way? As they are not specified by the Java standard
> I suppose they will be not.
No, the names will not be protected by technical means, unless perhaps
we find that people start abusing them.
> This leads to the question if other
> Java/JDK vendors and implementors will be able to define and deliver
> their own set of "incubator modules"?
Other developers are perfectly free to use the mechanisms behind
incubator modules (i.e., the `--warn-if-resolved` option), but they
should use module names that don't start with `jdk.`.
> 6. How do you intend to prevent "Java fragmentation" with regard to
> "supported incubator moduls"?
"Supported incubator modules" is an oxymoron. You can't depend upon
incubator modules -- they have a finite lifetime and can change or even
disappear without any notice at all. Fragmentation isn't really an
issue since incubator modules are, by their nature, self-fragmenting to
> OpenJDK/OracleJDK are currently for sure
> the most dominant by by no means the only Java implementations on this
> planet. Independent Java implementors may not be able to use OpenJDK
> incubator modules due to licensing issues. It is also unclear how
> Oracle will license incubator modules to its commercial licensees.
(I won't comment on Oracle's commercial license terms in this forum.)
> Finally, as already outlined in question 5, other Java/OpenJDK
> distributors may use this mechanism to establish their own set of
> incubator modules.
Yes, they are free to do so.
> 7. I would propose to impose a limit on how long a new feature can
> live in an incubator module (e.g. for one major Java release). I think
> this is essential to prevent "incubator modules" from becoming
> "de-facto" standards and thus effectively undermining the JCP process.
That is, in fact, an essential part of the proposal, as stated in the
Goals section: "The incubation lifetime of an API is limited: It is
expected that the API will either be standardized or otherwise made
final in the next release, or else removed."
Thanks for your feedback!
More information about the jdk9-dev