JEP 11: Incubator Modules

[Chris Hegarty]

Volker,

> On 7 Dec 2016, at 16:23, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
> 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/

Sorry, but I don’t see the similarities. 

The Endorsed Standards Override mechanism is being replaced by
Upgradeable modules [1].

The ultimate goal here is to provide a mechanism that facilitates better
APIs for the Java SE Platform, by incubating the feature first.


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

Yes. JEP 261 will be updated to cover these.

The run time implementation work is being tracked through 8170859 [2],
which I intend to bring for review on jigsaw-dev shortly.

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

I'm not sure how this is any different to JDK-specific APIs that we have
today. The intention here is to clearly identify these incubating features,
as opposed to the somewhat uncertain state of some 'jdk’ and ‘com.sun'
APIs in current releases.

A JEP is required for including an incubating feature in the JDK, just
like any other feature.


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

The JDK has had types in packages that start with 'jdk.' since 1.7, and
this has not been a problem. Do you see some specific issue with
module names, as opposed to package names?

-Chris.

[1] http://openjdk.java.net/projects/jigsaw/goals-reqs/03#upgradeable-modules
[2] https://bugs.openjdk.java.net/browse/JDK-8170859