Dynalink normally uses unreflect with publicLookup to get method handles for j.l.reflect.Method objects (found reflectively). But, publicLookup can not be used to unreflect caller sensitive methods. So, dynalink uses specific Lookup object from the callsite - for example, lookup of the Nashorn script (generated) class. But, script module has to have read-edge the module of the CallerSensitive method's class - or else that unreflect will fail.
Dynalink used to automatically add those necessary add edges. With the current change, nashorn adds necessary read edges. CallerSensitive methods are found only in java.base, java.logging, java.sql and java.sql.rowset modules - the first two are always present [in nashorn's compact1 dependency world]. The later two are checked for presence and read-edges are added conditionally (see ScriptLoader.java changes). Yes, I need boot layer modules only and I'll change that. -Sundar On 10/12/2016 8:51 PM, Alan Bateman wrote: > On 12/10/2016 16:11, Sundararajan Athijegannathan wrote: > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8167614 >> >> jdk webrev: http://cr.openjdk.java.net/~sundar/8167614/jdk/webrev.00/ >> >> nashorn webrev: >> http://cr.openjdk.java.net/~sundar/8167614/nashorn/webrev.00/ >> > In jdk/nashorn/internal/runtime/Context.java then it checks if the > java.sql and java.sql.rowset are observable. This does not mean they > are in the boot layer, I think you want > Layer.boot().findModule("java.sql").ifPresent(...). However, the this > code in Nashorn makes me wonder if this is actually needed or why > these two are special cased. > > -Alan
