JEP 11: Incubator Modules

[mark.reinhold at oracle.com]

2016/12/7 8:23:03 -0800, volker.simonis at gmail.com:
> 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/

There are at most superficial similarities, I think, since these
mechanisms weren't specifically intended for incubating features.

> 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:
>>> ...
>>> 
>>> 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 intent is that incubator modules whose names start with `jdk.`
be just those that originate in an OpenJDK Release Project and thus
represent ongoing work that has a significant amount of support from
experienced developers in the OpenJDK Community.  Developers at large
can infer from the name that a `jdk.` incubator module comes from a
serious project and so is more likely worth their time to evaluate
and test than some random module.  The `jdk.` prefix is, in essence,
a brand, and a useful one in this context.

Now sure, anyone can prefix a module name with `jdk.` today -- heck,
you can even prefix a module name with `java.` -- but to do so would
confuse developers and dilute a useful brand.

I'd rather not propose any kind of hard and fast rule here, and anyway
it'd probably not be enforceable.  If an implementation downstream of
OpenJDK wants to ship its own `jdk.` incubator module unrelated to any
ongoing effort in the OpenJDK Community then I'd likely advise against
it, to avoid confusion, but it'd just be advice.  If we find that lots
of random people start distributing `jdk.` modules, incubators or not,
and that confusion ensues then I think it'd be perfectly reasonable to
add code to the JDK to ignore such modules unless they're actually part
of the build.  Downstream implementors could adjust that code as needed,
of course, to add their own `jdk.` incubator modules.

- Mark