8181087: Module system implementation refresh (6/2017 update)

Mandy Chung mandy.chung at oracle.com
Thu Jun 15 05:37:33 UTC 2017

> On Jun 14, 2017, at 9:52 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> It's time to bring the changes accumulated in the jake forest into jdk9/dev. I'm hoping we are near the end of these updates and that we can close the jake forest soon.
> A summary of the changes that have accumulated for this update are listed in this issue:
>    https://bugs.openjdk.java.net/browse/JDK-8181087
> Aside from the important spec/javadoc updates, this update will bring the -illegal-access option into JDK 9 to replace the --permit-illegal-access option.
> The webrevs with the changes are here:
>  http://cr.openjdk.java.net/~alanb/8181087/1/

2453                     reflectionFactory.getExecutableSharedParameterTypes(method),

reflectionFactory should be accessed via getReflectionFactory().  I see Peter
already comments on this.

 901     void implAddOpensToAllUnnamed(Iterator<String> iterator) {
 902         if (jdk.internal.misc.VM.isModuleSystemInited()) {
 903             iterator.forEachRemaining(pn ->
 904                 implAddExportsOrOpens(pn, ALL_UNNAMED_MODULE, true, true));
 905             return;
 906         }

AFAICT this should only be called during module system initialization.
When will this method be called after initPhase 2?

 406     public Enumeration<URL> getResources(String name) throws IOException {
 407         // this loader
 408         List<URL> urls = findResourcesAsList(name);
 410         // parent loader
 411         parent.getResources(name).asIterator().forEachRemaining(urls::add);
 413         return Collections.enumeration(urls);
 414     }

We could consider returning an Enumeration that defers finding resources
from parent class loader after iterating the local resources.

   line 406, 418 the formatting seems off.

 408     private static final Attributes.Name AUTOMATIC_MODULE_NAME
 409         = new Attributes.Name("Automatic-Module-Name");

Should this be defined in java.util.jar.Attributes.Name?


1174                     } else if (!isAssignable(clazz, serviceName)) {
1175                         fail(service, clazz.getName() + " not a subtype”);

Peter raises the question on isAssignable that I think it should look at the interfaces recursively.  On the other hand, I wonder if this should simply fail if service.isAssignableFrom(clazz) returns false (which I think it’s the existing JDK 8 behavior).


More information about the hotspot-runtime-dev mailing list