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
