JEP 11: Incubator Modules

Wed Dec 7 16:23:03 UTC 2016

Hi Mark,

thanks a lot for the clarifications. After having slept on this I
think that this reminds me at least partially of the old and now
deprecated "Endorsed Standards Override" [1] and "Java Extensions" [2]
mechanisms :)

[1] https://docs.oracle.com/javase/6/docs/technotes/guides/standards/
[2] https://docs.oracle.com/javase/8/docs/technotes/guides/extensions/

Please find my additional remarks inline:

On Tue, Dec 6, 2016 at 5:28 PM,  <mark.reinhold at oracle.com> wrote:
> 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 [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.
>
> 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
> JEP.
>

So new features like the "--do-not-resolve-by-default" and
"--warn-if-resolved=incubator" will be part of JEP 261 right?

>>          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.
>
> 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
>> standard?
>
> 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
> specification.
>
>>           Are others allowed to use this mechanism for exposing
>> internals of standard modules trough their own incubator modules?
>
> It's fair game for an SE implementation that's downstream of OpenJDK
> to introduce qualified exports from JDK modules to its own, additional
> incubator modules.  What's not possible, or is at least extremely
> inadvisable, is for modules that aren't delivered as part of a JDK
> build to have this kind of intimate connection with JDK modules.
>
> If a downstream implementation adds its own incubator modules then
> it'd be best for the names of those modules to start with something
> other than `jdk.`, so as to avoid confusion.

But after this JEP, users will expect that incubator modules live in
"jdk.incubator" and as far as I understood, that's fine because the
"jdk" and "jdk.incubator" namespaces are not protected in any way. I
expect that not only downstream implementations but also interested
parties may use this mechanism to showcase extensions which they
eventually want to propose for inclusion into the OpenJDK.

In my eyes that would be a legitimate use case. If I have an
ultra-cool library which requires access to some internal JDK classes
I could build my own OpenJDK and add my library as incubator module.
This would allow me to easily distribute it in order to collect
feedback before I finalize my library and propose it for integration
into OpenJDK.

>
>> 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.`.
>

See my comment above. I think it wouldn't be fair to limit the usage
of modules starting with 'jdk.' to "OpenJDK-approved" modules because
the JEP states that "an incubator module identifies itself via the
jdk.incubator. prefix in its module name..and.. via the jdk.incubator.
prefix in its exported package names". So if a downstream
implementation should be able to add its own incubator module, it
should also be able to place it in a module starting 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
> start with.
>
>>                               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."
>

Sure. That was too obvious :)

Thank you and best regards,
Volker

> Thanks for your feedback!
>
> - Mark