8173393: Module system implementation refresh (2/2017)

[Peter Levart]

Hi Alan,

On 02/09/2017 10:28 PM, Alan Bateman wrote:
> On 07/02/2017 13:23, Alan Bateman wrote:
>
>> I will re-generate the webrevs later in the week once jdk-9+156 is 
>> promoted before eventually merging with jdk9/dev in advance of the 
>> eventual push.
> I've sync'ed up jake to jdk-9+156 and re-generated the webrevs:
>    http://cr.openjdk.java.net/~alanb/8173393/3/
>
> Assuming that nothing significant comes up then these are the changes 
> that I'd like to push to jdk9/dev for jdk-9+157.
>
> -Alan

First, just a nit...

java.lang.module.Resolver:

  320     private void addFoundModule(ModuleReference mref) {
  321         ModuleDescriptor descriptor = mref.descriptor();
  322         nameToReference.put(descriptor.name(), mref);
  323
  324         if (descriptor.osName().isPresent()
  325                 || descriptor.osArch().isPresent()
  326                 || descriptor.osVersion().isPresent())
  327             checkTargetConstraints(descriptor);
  328     }

...perhaps more correct would be to reverse the order: 1st check target 
constraints and then add descriptor to map. Otherwise in case of check 
failure, you end up with a Resolver instance that is poisoned with 
incompatible module descriptor. Maybe you always throw away such 
Resolver if this method fails, but maybe someone will sometime try to 
recover and continue to use the Resolver for rest of modules?


...then something more involving...

java.lang.reflect.AccessibleObject::canAccess could share access cache 
with internal method checkAccess. In particular since one might use this 
new method in scenarios like:

Method method = ...;

if (method.canAccess(target)) {
     method.invoke(target, ...);
} else {
...

Here's what you could do:

http://cr.openjdk.java.net/~plevart/jdk9-jake/AccessibleObject.canAccess_caching/webrev.01/


Regards, Peter