JEP 11: Incubator Modules

[Volker Simonis]

On Fri, Dec 2, 2016 at 6:20 PM,  <mark.reinhold at oracle.com> wrote:
> New JEP Candidate: http://openjdk.java.net/jeps/11
>

Hi,

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 [1] 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.

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. 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" [2] 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.

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"?

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
standard? 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. 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"?

6. How do you intend to prevent "Java fragmentation" with regard to
"supported incubator moduls"? 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.
Finally, as already outlined in question 5, other Java/OpenJDK
distributors may use this mechanism to establish their own set of
incubator modules.

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.

Thank you and best regards,
Volker

[1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
[2] https://bugs.openjdk.java.net/browse/JDK-8042950


> - Mark