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.
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:
> 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.