User-Agent: Mozilla/5.0 (Windows; U; Win98; de-AT; rv:1.2.1) Gecko/20021130 Build Identifier: Mozilla/5.0 (Windows; U; Win98; de-AT; rv:1.2.1) Gecko/20021130 First access to a method in a java applet is much slower than a second one. Reproducible: Always Steps to Reproduce: 1. Load attatched file - if possible use a slow machine 2. (Optional) In Java Console, press 5 3. Press the button 4. Press the button again Actual Results: The fist time the button is pressed it took a while for the message to display. The second time it is much faster. Expected Results: Same speed on all accesses. The problem also occures on "real" applets - the java.applet.Applet in the sample is just to keep it simple. The problem also occures on Windows XP. On fast systems the delay is shorter. The java console shows (after pressing 5): Java(TM) Plug-in: Version 1.4.1_01 Using JRE version 1.4.1_01 Java HotSpot(TM) Client VM Trace level set to 5: basic, net, security, ext, liveconnect ... completed. JavaScript: calling Java system code JavaScript: default security policy = http://localhost JavaScript: calling Java system code JavaScript: default security policy = http://localhost JavaScript: calling Java system code JavaScript: default security policy = http://localhost JavaScript: calling Java system code JavaScript: default security policy = http://localhost JavaScript: calling Java system code JavaScript: default security policy = http://localhost [... lots and lots of this messages ...] JavaScript: calling Java system code JavaScript: default security policy = http://localhost

Sounds like we lazily initialize some stuff on the first LiveConnect access... That is as it should be. What problems is this causing?

LiveConnect initializes the JVM when requested to do so. Reassigning to OJI; cc'ing Patrick. I think we began initializing Java lazily due to bug 26516, "Java/plugins initialize at startup"

> LiveConnect initializes the JVM when requested to do so But as the applet is already loaded I think the JVM is initialized. It is not good for the user to wait that long after a button-click (Over 15 seconds on my system when loading the page as file and over 5 when loading via http). IE works imediately.

->me

*** Bug 187649 has been marked as a duplicate of this bug. ***

Same on win 2k version 1.5 final with Java Plug-in 1.4.2_04 for Netscape Navigator. The call is not slow in my case the call never returnes. here is part of the trace: Starting applet ... JavaScript: calling Java system code JavaScript: default security policy = http://bugzilla.mozilla.org JavaScript: calling Java system code JavaScript: default security policy = http://bugzilla.mozilla.org JavaScript: calling Java system code ... goes on forefer untill I close mozilla then I get: Stopping applet ... Unregistered modality listener Joining applet thread ... Destroying applet ... Disposing applet ... Joined applet thread ... Quiting applet ... Finding information ... Releasing classloader: sun.plugin.ClassLoaderInfo@110c31, refcount=0 Caching classloader: sun.plugin.ClassLoaderInfo@110c31 Current classloader cache size: 1 Done ... yet some thread must still be runnint because JavaScript: calling Java system code JavaScript: default security policy = http://bugzilla.mozilla.org ... goes on forever untill I kicked mozilla.exe from task manager then Mozilla and the java console closes. Got another test case attached (win2k.zip) with the log (trace set to full)

Reproduce to show that javascipt to java doesnt work with w2k sp3 mozilla 1.5 and java Plug-in 1.4.2_04 for Netscape

w2k sp3 mozilla 1.6 final and java Plug-in 1.4.2_04 for Netscape Same problem

Correction to my post "the call never returnes". It does but with full tracing on it takes much more that 20 seconds. Am I correct in assuming that SUN will pick this up? (gotta download 1.5 and check) http://developer.java.sun.com/developer/bugParade/bugs/4518207.html

Even jre 1.5 can not fix it. This slowness is in mozilla side - liveconnect code reflects all the java method at the first time, hundreds java methods will be reflected, that will take too much time. We are trying to fix it with a new design of liveconnect. Hopefully we can make it in jre1.5.1 and mozilla 1.9/2.0.

(In reply to comment #11) Could you tell me where in the Mozilla source code these methods are reflected? I consistently experience the problems reported here on Win2K SP4 with JRE 1.4.2 or 1.5.0 and either Mozilla 1.7.5 or Firefox 1.0. But the same simple JavaScript-to-Java LiveConnect works just fine on OS X (using the Java Embedding Plugin and its MRJ Plugin JEP http://javaplugin.sourceforge.net/) -- no delay at all, even the first time. Maybe the "method reflection" doesn't take place on OS X ... or maybe something else is going on. (I haven't tested on Linux or Solaris.) Here's some evidence that the "method reflection" doesn't take place on OS X (when using the JEP and MRJ Plugin JEP): Even with the Java Console's "tracing level" set to 5, no Java-generated debug messages (e.g. "JavaScript: calling Java system code" or "JavaScript: default security policy = http://bugzilla.mozilla.org") appear there when doing simple JavaScript-to-Java LiveConnect.

(Following up comment #12) > Here's some evidence that the "method reflection" doesn't take place > on OS X (when using the JEP and MRJ Plugin JEP): Even with the Java > Console's "tracing level" set to 5, no Java-generated debug messages > (e.g. "JavaScript: calling Java system code" or "JavaScript: default > security policy = http://bugzilla.mozilla.org") appear there when > doing simple JavaScript-to-Java LiveConnect. Oops ... this _isn't_ evidence that the "method reflection" isn't taking place on OS X (with the JEP and MRJ Plugin JEP). Unlike the OJI Plugin, the MRJ Plugin JEP doesn't use sun.plugin.liveconnect.SecureInvocation (which is what displays all those messages). (In its place the MRJ Plugin JEP uses its own netscape.oji.LiveConnectProxy class.) My original question still stands, though.

(http://lxr.mozilla.org/seamonkey/source/js/src/liveconnect/jsj_method.c#515) Please refer to the jsj_ReflectJavaMethods in jsj_method.c. It needs 4 jni calls for only one method reflection. The jni call is very expensive in Sun's java plugin implemetation, not sure about Mac's.

(In reply to comment #14) Thanks for the info! jsj_ReflectJavaMethods() seems to work just the same on OS X as it does on Windows: It's called just once on an applet (on the applet's class) the first time you connect to it using JavaScript-to-Java LiveConnect, but that single call generates _lots_ of JNI calls. (I found this out by adding printf calls to jsj_ReflectJavaMethods() and building my altered jsj_method.c into a debugging version of Mozilla 1.7.5 for OS X.) However, the MRJ Plugin Carbon (upon which my MRJ Plugin JEP is based) seems to be orders of magnitude more efficient in its handling of these JNI calls than Sun's Netscape-4-style and OJI-style plugin libraries (NPJPI150_01.dll and NPOJI610.dll). Things are so bad that I consider this a bug in these libraries. At least one other person agrees with me: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5097873 But Sun has closed this and marked it "not a bug". Like you, they seem to be waiting for a change in the LiveConnect architecture to make the initialization of JavaScript-to-Java LiveConnect more efficient. I agree that, with the right kinds of architecture changes, jsj_ReflectJavaMethods() could be made much more efficient -- for example, it'd be nice if the Java plugin libraries supported a single "initializeLiveConnect" call. But these kinds of changes involve several independant parties ... which means they usually take a long time. In the meantime, I suspect Sun could really do a much better job. I don't know to what extent you are Sun's representative in this matter. But if you have the time (and are interested), you might want to take a look at the MRJ Plugin Carbon's code. By the way (in case you didn't already know it), I'm the Java Embedding Plugin's author. And what I call the "MRJ Plugin JEP" is based on Mozilla.org's MRJ Plugin Carbon (http://www.mozilla.org/oji/MRJPluginCarbon.html (CFM build), ftp://ftp.mozilla.org/pub/mozilla.org/camino/releases/MRJPlugin.gz (Mach-O build), and also bundled with the Mozilla source distro). I don't know who wrote the original "MRJ Plugin" (http://www.mozilla.org/oji/MRJPlugin.html), but it seems that Patrick Beard ported it to the Carbon environment, and is responsible for its very efficient handling of JavaScript-to-Java LiveConnect. My own contribution (what makes the MRJ Plugin JEP different from the MRJ Plugin Carbon) was to add support for the Java Embedding Plugin and to fix a lot of bugs (LiveConnect, in particular, was unusably buggy, at least in the Mach-O build -- so much so that it's turned off in Camino's Mach-O distro cited above). The heart of the MRJ Plugin Carbon's (and MRJ Plugin JEP's) JavaScript-to-Java implementation is sendMessageToJava() in CSecureEnv.cpp. To see how its security model works (and it does have a good one), look at createClassLoader() and the ProxyClassLoader class in ProxyClassLoaderFactory.java, and the LiveConnectProxy class (in LiveConnectProxy.java).

(Following up comment #15) > The heart of the MRJ Plugin Carbon's (and MRJ Plugin JEP's) > JavaScript-to-Java implementation is sendMessageToJava() in > CSecureEnv.cpp. To see how its security model works (and it does > have a good one), look at createClassLoader() and the > ProxyClassLoader class in ProxyClassLoaderFactory.java, and the > LiveConnectProxy class (in LiveConnectProxy.java). One more thing: What ties these two elements together is GetLiveConnectProxy() in CSecureEnv.cpp (it's called from sendMessageToJava() and it calls ProxyClassLoaderFactory. createClassLoader()).

mass reassign to Alfred

I'm having a similar problem. I was planning to posting a separate ticket; however commenting here might reach the right people faster. One of my coworkers discovered that the MRJPlugin.jar's ProxyClassLoaderFactory class includes the line: System.out.println("<<< " + message + " >>>"); This displays tons of output to the Java Console that can't be turned off without modifying the source for MRJPlugin.jar and rebuilding it. I'm using Firefox 2.0.0.14 with Java 1.5's Plugin.jar to allow Java Applets to callback Javascript functions and vice versa. Here's an example of what appears in the Java Console repeatedly as applet-to-javascript calls are made: <<< ProxyClassLoader: defined LiveConnectProxy class. >>> <<< Here're the permissions you've got: >>> <<< java.security.Permissions@b614d0 ( (java.net.SocketPermission 127.0.0.1 connect,accept,resolve) ) Does anyone know if there is a good site keeping up with the latest MRJPlugin.jar releases?

WFM with Firefox 5.0 on Windows XP and Java 1.6.0.26.

Mass-closing bugs in the "OJI" component: OJI plugin integration was replaced with npruntime long ago, and these bugs appear to be irrelevant now. If there is in fact a real bug that remains, please file it new in the "Core" product, component "Plug-ins".