-
Enhancement
-
Resolution: Fixed
-
P3
-
9
-
b99
-
generic
-
generic
BrowserJSObjectLinker is lazily looking up netscape.javascript.JSObject, but unfortunately this means it's going through the superclass-traversing loop in canLinkType (which involves a potentially security-checking getClassLoader()) on every link request that reaches it. Adding a
System.err.println("Checking " + clazz.getName())
into the loop and running jjs prints:
$ ./jjs
Checking jdk.nashorn.internal.runtime.ScriptFunction
Checking jdk.nashorn.internal.runtime.ScriptObject
Checking java.lang.Object
jjs> print("x")
Checking jdk.nashorn.internal.objects.Global
Checking jdk.nashorn.internal.runtime.Scope
Checking jdk.nashorn.internal.runtime.ScriptObject
Checking java.lang.Object
x
and so on. It seems it's easier to just eagerly look up the class once.
System.err.println("Checking " + clazz.getName())
into the loop and running jjs prints:
$ ./jjs
Checking jdk.nashorn.internal.runtime.ScriptFunction
Checking jdk.nashorn.internal.runtime.ScriptObject
Checking java.lang.Object
jjs> print("x")
Checking jdk.nashorn.internal.objects.Global
Checking jdk.nashorn.internal.runtime.Scope
Checking jdk.nashorn.internal.runtime.ScriptObject
Checking java.lang.Object
x
and so on. It seems it's easier to just eagerly look up the class once.