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
