8170987: Module system implementation refresh (12/2016)
Alan.Bateman at oracle.com
Thu Dec 15 09:17:42 UTC 2016
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.
> 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.
More information about the compiler-dev