8170987: Module system implementation refresh (12/2016)

[Alan Bateman]

On 15/12/2016 01:17, Mandy Chung wrote:

> I have pushed the change to rename jdk.crypto.pkcs11 and jdk.pack200
> and dropped java.compact$N.  So module-info.java changes will not be
> needed when you sync with jdk9/dev.
Thank you. I'll do a merge today to see that everything works together.

> :
>
> Not sure if it’s intended to have the javadoc for isJavaIdentifier
> method be the same as isBinaryName.
We can drop it but it was left there to avoid needing to change the 
usages that will be changing once we sort out residual issues in the 
Builder API, specifically the uses/provides methods that don't yet do 
the right validation (the `provides` methods shouldn't allow simple 
names for example, it also needs to ensure that the builder can't create 
a ModuleDescriptor that claim to have a provider that is not in the 
module. So I think this will all clean itself up in time.

>
> When we use —-module-version for user modules, the runtime will load
> regex.  The system modules jlink plugin uses the cached version if
> JDK modules to be compiled with —0module-version in the future.
> This might be something we should look at in the future for performance.
I'm sure Claes will be interested in that although I don't think we have 
any need to compile the JDK modules with --module-version, except maybe 
for testing exploded modules.

>
> src/java.base/share/classes/jdk/internal/module/ModuleResolution.java
>
>    64             throw new RuntimeException("cannot add deprecated to " + value);
>
> This comment applies to ModuleResoluton::with* methods.  This should
> probably be an InternalError?
IllegalArgumentException will probably work here.

-Alan