- 
    Enhancement 
- 
    Resolution: Fixed
- 
     P3 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.