Closed Bug 26516 Opened 25 years ago Closed 23 years ago

java/plugins initialize at startup

Categories

(Core Graveyard :: Plug-ins, defect, P1)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9

People

(Reporter: warrensomebody, Assigned: beard)

References

Details

(Keywords: perf, topperf)

Attachments

(7 files)

proposed fix for not registering Java Plugin on startup
637 bytes, patch
Details | Diff | Splinter Review
Fix for this bug, second iteration.
706 bytes, patch
Details | Diff | Splinter Review
rough draft of different approach of not loading JVM
3.68 KB, patch
Details | Diff | Splinter Review
Patch to do 2 phase initialization of JSJavaVM objects.
4.53 KB, patch
Details | Diff | Splinter Review
Better patch (jsj_ConnectToJavaVM checks jsjava_vm->java_vm instead of jsjava_vm->jsj_created_java_vm)
4.24 KB, patch
Details | Diff | Splinter Review
Be more defensive about JSJavaVM usage.
7.80 KB, patch
Details | Diff | Splinter Review
Once more, with feeling, check result of jsj_ConnectToJavaVM()
7.83 KB, patch
Details | Diff | Splinter Review 
I've noticed that java initializes on startup, in fact all plugins do. It 
appears that the plugins directory is iterated through during startup and all 
the plugins are re-registered (in nsPluginHostImpl::GetPluginFactory). Since 
plugins can now just be viewed as components, we should rely on the standard 
component registration in xpcom to manage them. (Wasn't that the whole point of 
the 4.x plugin adapters, etc.?)

nsPluginHostImpl::GetPluginFactory takes 4.07% of startup time after 
eliminating idle times from Quantify, and time spent in LoadLibrary.
Keywords: beta1, perf
Whiteboard: [PDT+]
Giving to OJI owners.
Assignee: beard → drapeau
OJI is already an XPCOM service, and is registered as such.  Java Plug-In is a 
plugin that asks for the JVMManager XPCOM service.  I think there might be a 
couple of issues here, but Andrei Volkov is better equipped to answer this than 
I.  Here is my belief about the several issues:

1) Old-style plugins aren't loaded as components, so those plugins can't be
   managed in the XPCOM way (e.g., Shockwave, RealAudio, etc.).

2) Java being initialized on startup is a different bug: I believe that 
LiveConnect is causing the JVM to be started as a side-effect, a behavior which 
we will fix after Beta1.

I believe that the basic bug as being reported here is "plugins initialize at 
startup", so I'm re-assigning this to the Plugins module.
Assignee: drapeau → av
Component: OJI → Plug-ins
QA Contact: paw → shrir
Target Milestone: M15
Blocks: 21305
Must land a fix for this by 02/23 or we will PDT- (not fix) for beta1.
Whiteboard: [PDT+] → [PDT+] Must land by 02/23
Whiteboard: [PDT+] Must land by 02/23 → [PDT+] w/b minus on 02/25
I am removing PDT+ mark since 02/25 passed and we do not have fix in hand yet.
Status: NEW → ASSIGNED
Whiteboard: [PDT+] w/b minus on 02/25 → w/b minus on 02/25
Putting on PDT- for beta1.
Whiteboard: w/b minus on 02/25 → [PDT-]w/b minus on 02/25
Target Milestone: M15 → M16
Plugins folder is iterated through looking for old school plugins, and those 
should be registered at start up. The process on Windows should not be very 
costy since actual dll's are not being loaded at this time. Java initializes 
from LiveConnect, so I reassining to LiveConnect people to take a look.
Assignee: av → rogerl
Status: ASSIGNED → NEW
Component: Plug-ins → Live Connect
QA Contact: shrir → rginda
Ah yes, but LiveConnect initializes Java when OJI asks it to. What *exactly* is 
the bug here, is Java demonstrably slower to start-up than 4X ?
The bug here is that java consumes memory footprint and startup time 
unnecessarily. It should only get initialized when it's really needed, i.e. 
when the first applet is loaded.
OK, then I don't think this is a LiveConnect issue. LiveConnect initializes the 
JVM when requested to do so, which would be at the hands of OJI and drapeau has 
already indicated that's a Plugin's issue. This finger++ is hardly productive 
though - I'm happy to work with anybody to address this, I just don't see what 
LiveConnect can do about it?
Yes, this is a plugins issue. Java is just the worst-case scenario.

Just make plugin initialization lazy.
Reassigning back to myself.
Assignee: rogerl → av
Component: Live Connect → Plug-ins
QA Contact: rginda → shrir
I just discovered bug 18277 which is a dup. Av - can you work with drapeau to 
see who's going to own this?
2 betas would be better than one for shaking out major adjustments
to startup...  putting on beta2 radar
Keywords: beta1 → nsbeta2
Putting on [nsbeta2-] radar.  av already overloaded with beta2 work.  This is 
work for beta3.  Putting on nsbeta3 keyword radar.
Keywords: nsbeta3
Whiteboard: [PDT-]w/b minus on 02/25 → [nsbeta2-]
Reassigning to George, who's kindly volunteered to take this on. Thanks George!
Assignee: av → drapeau
Accepting this bug.
Status: NEW → ASSIGNED
M16 has been out for a while now, these bugs target milestones need to be 
updated.
For the record, it looks like the only reason the plugins dir is traversed on 
startup is for LiveConnect:

nsPluginsDir::nsPluginsDir(unsigned short 1) line 193
nsPluginHostImpl::LoadPlugins(nsPluginHostImpl * const 0x0154f644) line 2605 + 
10 bytes
nsPluginHostImpl::GetPluginFactory(nsPluginHostImpl * const 0x0154f644, const 
char * 0x01f6f684, nsIPlugin * * 0x0012fa24) line 2421
nsJVMManager::StartupJVM() line 567 + 32 bytes
nsJVMManager::MaybeStartupLiveConnect() line 741 + 20 bytes
nsJVMManager::StartupLiveConnect(nsJVMManager * const 0x0154e988, JSRuntime * 
0x00c6acf8, int & 0) line 128 + 11 bytes
nsJSEnvironment::nsJSEnvironment() line 1291 + 49 bytes
nsJSEnvironment::GetScriptingEnvironment() line 1236 + 27 bytes
NS_CreateScriptContext(nsIScriptGlobalObject * 0x0154d260, nsIScriptContext * * 
0x01548880) line 1331 + 5 bytes
nsDocShell::EnsureScriptEnvironment(nsDocShell * const 0x015487d0) line 3825 + 
50 bytes
nsWebShell::GetInterface(nsWebShell * const 0x015487f4, const nsID & {...}, 
void * * 0x0012fbf8) line 545 + 19 bytes
nsGetInterface::operator()(const nsID & {...}, void * * 0x0012fbf8) line 37 + 
31 bytes
nsCOMPtr<nsIDOMWindow>::assign_from_helper(const nsCOMPtr_helper & {...}, const 
nsID & {...}) line 856 + 18 bytes
nsCOMPtr<nsIDOMWindow>::nsCOMPtr<nsIDOMWindow>(const nsCOMPtr_helper & {...}) 
line 553
nsAppShellService::GetHiddenWindowAndJSContext(nsAppShellService * const 
0x01560550, nsIDOMWindow * * 0x0012fca8, JSContext * * 0x0012fcac) line 687 + 
32 bytes
nsAppShellService::CreateHiddenWindow(nsAppShellService * const 0x01560550) 
line 223 + 40 bytes
main1(int 2, char * * 0x00c74090, nsISupports * 0x00000000) line 881
main(int 2, char * * 0x00c74090) line 1099 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77f1b304()

If you disable Java using the Preferences Advanced option, the plugins dir 
doesn't get traversed at startup.  Thus I feel the correct thing to do would be 
to modify the nsJSEnvironment constructor to move the call to 
JVMManager::StartupLiveConnect() until it's actually needed.  Can someone 
please tell what I would need to change to do this?

Thanks,

Ed
Assignee: drapeau → edburns
Status: ASSIGNED → NEW
Pushback
Target Milestone: M16 → M18
Adding pavlov and making 35707 be a dependency.

/be
Depends on: 35707
I say yank it out of there. We don't do liveconnect now, and probably never will 
(given that it's JRI-based, i.e. dependent on the old netscape jvm).
Since when are we not support liveconnect?
Status: NEW → ASSIGNED
Liveconnect is based on JRI and is not part of your JVM. AFAIK, it has never 
worked in seamonkey, and never will.
Jeff Dyer needs to comment on this one.  I believe he *did* have LiveConnect
support working.  Just in case, I'm adding him to the CC list on this so he can
reply.
LiveConnect for JNI is implemented. The JRI based code was ported to JNI 
sometime last year. It has been working ever since, except as reported in 
Bugzilla.

> AFAIK, it has never worked in seamonkey, and never will. 

Perhaps you know something I don't. 
I only meant the JRI one would never work. I had forgotten that it got ported to 
JNI. Sorry for the confusion. 


Warren: no problem, that's cool, but we still could use some advice about how to
fix the bug so that the JVM gets requested to start up only at the moment it's
needed, not sooner.  If you know anybody who can help, that would be great. 
Otherwise, I will probably ask Jeff Dyer to help on this one, and he won't be
able to get to it right away because he's working on the completion of
Java-to-JavaScript security right now.

ETA 28 July 2000
The Java Plugin is registered on startup time, i.e.
  nsPluginHostImpl::GetPluginFactory
  nsJVMManager::StartupJVM
  nsJVMManager::MaybeStartupLiveConnect
  nsJVMManager::StartupLiveConnect
  nsJSEnvironment::nsJSEnvironment
The Java Plugin is also registered when an applet is 
loaded. If the Java Plugin is installed, I see
  nsPluginHostImpl::GetPluginFactory
  nsPluginHostImpl::SetUpPluginInstance
  nsPluginHostImpl::InstantiateEmbededPlugin
and the debugging message
  "For application/x-java-vm found plugin 
C:\mozilla\dist\WIN32_D.OBJ\bin\plugins\NPJava32.dll"
If the Java Plugin is not installed, I see
  nsPluginHostImpl::GetPluginFactory
  nsPluginHostImpl::SetUpDefaultPluginInstance
  nsPluginHostImpl::InstantiateEmbededPlugin
and message
  "For * found plugin 
C:\mozilla\dist\WIN32_D.OBJ\bin\plugins\npnul32.dll"

The proposed fix here is to modify 
  nsJVMManager::StartupJVM
so that the Java Plugin is not registered on startup,
see the attachment at 7/18/00.

For the plugins other than Java Plugin, I checked QTV plugin with URL,
 http://www.apple.com/trailers/paramount/mission_impossible_2/bts_med.html
With/Without my fix,  the 
  nsPluginHostImpl::GetPluginFactory 
is not called at startup time. It is called when I load the page and
I see the message,
  "For video/quicktime found plugin
   C:\mozilla\dist\WIN32_D.OBJ\bin\plugins\npqtplugin.dll"
I am not sure if there is other method to register QTV plugin at
startup time.

According George.Drapeau@eng.sun.com, the issue of not loading JVM at 
the startup time will be addressed at Bug 18277.
Cc'ing waterson.
I'm currently building.  I'll try this when it's built.
I like the simplicity of this fix, but it breaks the Menu function "Tasks-
>Tools->Java Console".  This fix prevents the body of StartupJVM from ever 
executing.  This needs to execute to enable the Java Console to work.
Thank Ed for caching up the problem of Menu function for 
Java Console in my proposed fix.  I tested your second 
iteration in following steps,
  Step 1. start mozilla which loading http://www.mozilla.org
  Step 2. load an applet, e.g.
     http://192.9.48.9/products/plugin/1.3/demos/applets/CardTest/example1.html
  Step 3. select menu "Tasks->Tools->Java Console" which starting
     Java Console.
Everything works fine and the method
   nsPluginHostImpl:GetPluginFactory. 
is not called on startup.   

However,  the Java Console doesn't start and I saw memory error in
   nsJVMManager::ShowJavaConsole(nsJVMManager * const 0x00d93c70) line 146
if I skip the step 2 above.
It looks like the patch #2 will block nsJVMManager::MaybeStartupLiveConnect from 
ever starting the vm. The problem is that Liveconnect and JVM initializiation 
are entangled. And, that there is code that depends on a running vm, that 
doesn't know how to start it. The solution (apparently) was just to start the vm 
at when the browser loads whether it is needed or not. Bug 27462 is another 
reason why this is a bad idea. The general solution requires that the vm not be 
started before it is needed (as is being done in the fix proposed here), and 
also that code that depends on the vm running, make it run (this part is 
missing from the proposed solutions).

Jeff, can you please give me some pointers on how to do the second part
of what you propose: "code that depends on the vm running, make it run"?  
Something of the form of filename/line-number pairs or even just class names 
would be great.

Thanks,

Ed

I'd start by factoring out LiveConnect and start the vm directly from those 
places where a running vm (without liveconnect) is needed. Once this is working 
properly, you can do the same for LiveConnect. 

Hope that helps to get you pointed in the right direction. Let me know if you 
want more help.
Making nsbeta3-
Whiteboard: [nsbeta2-] → [nsbeta3-]
Marking mozilla0.9. All tries to reduce mozilla memory footprint are totally
useless if Java is adding 7 MB of RAM bloat at each startup. This prevents Java
enabled small embedded browsers as well. Please reconsider priority of this bug.
Keywords: mozilla0.9
Adding to tracking bug for startup perf (7251).
Blocks: 7251
*** Bug 42262 has been marked as a duplicate of this bug. ***
reassign to joe
Assignee: edburns → joe.chou
Status: ASSIGNED → NEW
Priority: P3 → P1
*** Bug 18277 has been marked as a duplicate of this bug. ***
Blocks: 1785
Joe, any status?
I have not got a chance to look at this one closely yet. I'll look at it
tomorrow.
Jeff, would you be a little more specific about your second part of suggestions? 
>------- Additional Comments From Jeff Dyer 2000-07-20 12:57 -------
>
>I'd start by factoring out LiveConnect and start the vm directly from those 
>places where a running vm (without liveconnect) is needed. Once this is working 
>properly, you can do the same for LiveConnect. 

All I mean is find the places that the JVM is needed and initialize the Java 
plugin when execution reaches those places. Then find all the places where 
Livecconect is needed and initialize Liveconnect when execution reaches those 
places.

Before I'd mess with the code though, I'd do a top-down review of the design to 
see if there is a need to revise the way either of these components are started. 
For example, I'd look for any dependencies that force LC to start when the VM is 
started.

To my understanding, with today's build on Windows, in
nsJVMManager::MaybeStartupLiveConnect(void) we make a call to
JSJ_ConnectToJavaVM(NULL, NULL) which causes java to start. 

Specifically, in JSJ_ConnectToJavaVM(NULL, NULL), we check if we hava a Java VM 
and if we do, we call
JSJ_callbacks->create_java_vm(&java_vm, &jEnv, initargs)

which starts Java (and the little guy in the system tray).

Can this somehow be differed untill needed? It's probably a huge memory and 
performance gain to lazily start Java.

Target milestone is set for M18, I nominate Mozilla 0.9?
Yeah, this bug needs a valid Target Milestone.  Joe?

/be
Yes, Mozilla 0.9 sounds fine.
Status: NEW → ASSIGNED
Changed milestone from m18 to mozilla0.9.
Target Milestone: M18 → mozilla0.9
Keywords: nsbeta2, nsbeta3 → nsbeta1, topperf
Whiteboard: [nsbeta3-]
this bug has such a long and sorted history....
wondering if the fix for this is well understood and on track for 0.9?
Yes, Mozilla0.9 is too soon for this fix (which is planned to be release on 19th
of March?). Based on Jeff's suggestions, the fix seems to have multiple changes,
and requires more time to test as well. I've been working on some urgent bugs
recently, and I need to change the milestone to Mozilla0.9.1. Any objections?
My only comment is that it's a high priority to improve startup as
soon as we can.  The faster we can get to this bug the better.
Why not leave this at 0.9 for now -- we're seriously contemplating a numbering
change to make the current milestone be 0.8.1 (announcements and roadmap update
soon), and I'd hate to take pressure off this bug, or even fiddle with its
fields for no gain.

/be
Blocks: 71373
This patch attempts to skip the loading of Java from the plugin point of view, 
as if the libraries weren't in the folder. Check about:java and they aren't 
even registered. However, now that nsPluginHostImpl::ReloadPlugins() works, I 
set flags to trip skip loading until it finds the Java mime-type. 

However, there are a few bugs left like it calls ReloadPlugins twice and the 
Java Console Menu Item stays disabled. 

Also, I haven't tested this patch extensivly, I don't know what I broke 
(LiveConnect, which I was told does not work anyway, perhaps?). Seems to save 
loading time and memory on my system.
LiveConnect *does* work; not completely, but we're fixing LiveConnect bugs as we
encounter them.

Shrirang or Raju, can either of you point Peter to some LiveConnect tests that
he could try with his patched build?
Most of the Test case we have are inside SUN. Not sure if Peter would be able to
access those.

There are some on the mozilla site (mayb devlped by Shrirang).
 http://www.mozilla.org/quality/browser/front-end/testcases/oji/

He should be able to find some tests there.


Wait a sec, LiveConnect does work? I was told it doesn't. Does it work/will it 
work for 4.x plugins if we hook up the Java functions for LiveConnect in 
ns4xPlugin? 

I think plugin vendors would be VERY happy if we could provide backwards support 
for LiveConnect.
Blocks: 71781
No longer blocks: 7251
Oops, sorry about that.  I don't know if LiveConnect works for plugins.  I know
it partially works for Java applets calling JavaScript and vice versa, but I
don't know about how plugins fit into the scheme.

Do you have a test we could try?
I don't know how to evaluate Peter's changes to see if they're good or not.  The
change sounds like a hack, but it looks like it works!  Who am I to block this fix?

I am *not* Brendan Eich, or Patrick Beard, or Ed Burns.  So, I'm copying them to
see if they can make a ruling.

Also, does anybody know here why LiveConnect doesn't work in plugins?  Could use
some explanation/help/history here, or elsewhere if this bug is not appropriate.
@@ -3319,9 +3329,12 @@
 {
   // do not do anything if it is already done
   // use nsPluginHostImpl::ReloadPlugins to enforce loading
-  if(mPluginsLoaded)
+  if(mPluginsLoaded && mLoadJava)
+    return ReloadPlugins(PR_FALSE);
+  else if (mPluginsLoaded)
     return NS_OK;

could be:
   if(mPluginsLoaded)
-    return ;
+    return (mLoadJava)?ReloadPlugins(PR_FALSE):NS_OK;

indentation of patch looks inconsistent, and possibly tab ridden,
esp near 
+void nsPluginHostImpl::EnableJava(PRBool aLoadJava)
+{
+    if (mJavaCalledBefore)
+               mLoadJava = aLoadJava;
+       else
+               mJavaCalledBefore = PR_TRUE;
 }
why reset mJavaCalledBefore ??
If we don't load Java/OJI at startup, won't LiveConnect fail to initialize? 
Before we check in lazy initialization, I'd like to verify that the code in DOM 
that initializes LiveConnect still works.
Blocks: 7251
Keywords: nsCatFood
Joe, any word on this?  Can someone answer beard's question?
I am trying to figure out Jeff Dyer's suggestion, in compairesion with the
patches provided here. 
I think we all agree with Patick here that the fix should not break liveConnect.
Andrew or Peter can you guys also help take a look at this?
No longer blocks: 71373
I'll take a look at it tonight.
I agree that we can probably defer the call in nsJSEnvironment::nsJSEnvironment() 
that eagerly calls nsILiveConnectManager::StartupLiveConnect(), but as soon as 
the first nsJSContext object gets created, its 
nsJSContext::InitializeLiveConnectClasses() method will get called, and so we'll 
have to do it there, which is still too eager. The solution to this problem is to 
initialize the nsJSContext's global object with the LiveConnect root properties, 
"Packages", "java", and "netscape", such that the first time they are evaluated, 
THEN the call to nsILiveConnectManager::StartupLiveConnect(), and 
nsILiveConnectManager::InitLiveConnectClasses() occurs. What I'm not clear on, is 
how to do this handoff cleanly, such that after this has happened, the values for 
these properties change to their proper values.

jband and brendan can provide more technical details.

jst, what's the best way to define properties lazily?  There are the
aLazyPropSpec params to nsJSUtils::nsGlobalResolve and nsGlobalEnumerate, which
come from 'replaceable' DOM IDL attributes, but DOM IDL is going away.  There is
the nsIScriptNameSpaceManager/nsIScriptNameSetRegistry jazz, but I believe that
too is changing on the DOM-over-XPConnect branch.  Pls. advise,

/be
No longer blocks: 7251
I've been trying different test cases with some code changes, and found out the
following:
The main problem seems to be to delay starting LiveConnect (if it is done
correctly, lazy starting JVM seems requiring no code change). An ideal place to
start LiveConnect would be when a page is found to have JavaScript data types.
But in my tracing, I've not found the code parsing JavaScript data types
(Packages, java, etc.) in a page. Instead, I did see the code that initializing
all the JavaScript data types for any page. If that is true (currently the
browser does not parse to see if a page contains JavaScript), then I guess we
may need to add code to do the parsing, and if a page is found to have
JavaScript, start LiveConnect (along with starting JVM, as the current code
does). 
Am I missing something here?

Can we adapt the ResolveStandardClasses stuff for LiveConnect?  That'd let us
pull in JavaPackage and the like when they're first used.

Parsing the script and looking for references to Package and whatnot is a
non-starter, really, since it requires evaluation of the script.

Should I look at doing JSJ_ResolveLiveConnectClasses?  joe.chou, can you post
your patches that get the non-LiveConnect issues resolved?

shaver is referring to the JS API's JS_ResolveStandardClass, which tries to bind
a standard name to its property value (Object, Date, RegExp, etc.) and returns a
flag telling whether it did bind.  JSJ_ResolveStandardPackage is a better name
for the liveconnect function, as "Packages", "sun", "netscape", and "java" are
package, not class, names.

The call would come from GlobalWindowImpl::Resolve, in
dom/src/base/nsGlobalWindow.cpp.

/be
I'm posting this message on behalf of Joe to say that he has been away since
Monday, and is expected to be back tomorrow.  That's why there's no progress on
this bug since Brendan's last comment.
What Mike is proposing seems to be the thing missing. If that can be done to
only start LiveConnect when one of the packages is first used, that would be a
good solution to this problem. I believe that Mike's suggestion also fits what
Patrick was refering to in his earlier comments. If that is true, then Mike
would you please come up with the fix to do the lazy start of LiveConnect?

With the late start of LiveConnect in place, lazy start of JVM is also done
without any other code changes. Therefore, there is no need for other patch,
unless you want to polish the code a bit. Talking about polishing the code, I do
suggest a replacement for MaybeStartupLiveConnect():

PRBool
nsJVMManager::MaybeStartupLiveConnect(void)
{
    // If LiveConnect already started, do nothing.
    if (fJSJavaVM) {
        return PR_TRUE;
    }

    if (!IsLiveConnectEnabled()) {
        return PR_FALSE;
    }

    JVM_InitLCGlue();
    fJSJavaVM = JSJ_ConnectToJavaVM(NULL, NULL);
    if (fJSJavaVM != NULL) {
        return PR_TRUE;
    } else {
	// Log error?
        return PR_FALSE;
    }
}

There is no need to call StartupJVM in MaybeStartupLiveConnect(), since
JSJ_ConnectToJavaVM() eventually calls StartupJVM() if JVM has not been started.
The do_while is no longer needed, and it only loop once anyway (while (0)).
On the other hand, the current MaybeStartupLiveConnect() still works without any
changes.

The only changes needed seems to be the following two
1) Add the code that Mike is proposing, (JSJ_ResolveStandardPackage?), which
calls MaybeStartupLiveConnect() when a package is first used. 
2) Remove the line of code calling StartupLiveConnect(), which calls
MaybeStartupLiveConnect() in the initialization of the browser, in
nsJSEnvironment::nsJSEnvironment().


One additional point to consider:  if an applet decides to use the JSObject API, 
but its page has no LiveConnect global references, we need to make sure that this 
also initializes LiveConnect. Perhaps when nsObjectFrame loads an applet, if its 
MAYSCRIPT attribute is defined, we also initialize LiveConnect.

Just to be on the safe side, Patrick, when you implement the delay startup of
LiveConnect, please also consider the case of JavaScript-to-Java communitcation
(e.g., document.Myapplet.doSomething() should still work), MAYSCRIPT should have
covered JAVA-to-JavaScript part.
The problem with the whole JSJ_ResolveStandardPackage() approach, is that Caps 
defeats the whole intent in |nsSecurityNameSet::InitializeClasses()|, because it 
causes "netscape.security" to be resolved. My original idea, eagerly populating 
the global namespace with package objects for java, netscape, sun, and Packages, 
plus a set of sub-packages, such as netscape.security, seems to be the only 
practical solution to this problem. This requires splitting up LiveConnect's 
initialization into 2 phases, essentially predefining all of the interesting 
packages first, and then if properties are read from any of those predefined 
package, firing up Java at that point using the OJI module callbacks.

Here's an initial cut at an attempt to perform 2 phase initialization. Basically, 
I've delayed the full initialization of JSJavaVM objects until the first call to 
JSJ_AttachCurrentThreadToJava(). I haven't checked to see if this is completely 
bullet proof, but it does successfully defer the loading of the MRJ plugin until 
LiveConnect is actually running.

Taking bug.
Assignee: joe.chou → beard
Status: ASSIGNED → NEW
I was planning to switch those netscape.security calls in caps over from
ScriptExternalNameSet declaration to being XPConnected objects; will this make
things easier? If so, I'll make that a priority.
No, as long as you are writing ANY sort of object in to "netscape.security" there 
will be an impact on LiveConnect. Luckily, I've worked out a way to lazily 
initialize LiveConnect that should work regardless.

I am seeking commentary on this patch.
Status: NEW → ASSIGNED
I have verified that it works on Linux; Java doesn't start until I load an Applet 
or evaluate javascript:java.lang.System. The Linux plugin does have a tendency to 
hang the browser however...

verified on win32, the patch builds, there's no java icon in the taskbar after
we start up.  When I go to a page with an applet, the icon appears and java's
running.

go team!!
I tried the patch on Solaris (the patch should have included the removing of the
line of calling StartupLiveConnect() in nsJSEnvironment::nsJSEnvironment()), and
it seemed to work ok with the cases with Applet tags. But for a case without an
applet tag (see attachment below), it seemed not invoking call to Java. For
example, I set a breakpoint at getContext in ProxyJNI.cpp. Without the patch
(LiveConnect and JVM started at init), the breakpoint was hit, which then invoke
the call method to Java plugin and JVM. With the patch, the breakpoint somehow
was not hit, and no call method invoked. Is my test case valid? I might have
missed something there.

Attachment of the test case (simplified test case from 60018):

Another test HTML (with a button):
<html>
<head> <title>Live Connect using a JavaObject</title> </head>
<body>
<form ID="form1" name=myForm>
        <input ID="field1" Type=text value="Live Connect using a JavaObject"
         name="fieldOne">
        <input ID="button1" Type=button value="Call load()" name="buttonOne"
         onClick=click_doit()>
        <input ID="field2" Type=text value="Live Connect using a JavaObject"
         name="fieldTwo">
        <input ID="button2" Type=button value="Call showAlert()"
         name="buttonTwo" onClick=showAlert("showAlert()")>
</form>
<script>
        function click_doit()
        {
                java.lang.System.out.println("*** calling new Cherokee() ");
                var htmlForm = new Packages.Cherokee("Hello");
                java.lang.System.out.println("*** skip calling load() ");
                <!-- htmlForm.load(params); -->
                java.lang.System.out.println("*** calling load() done");

        }

        function showAlert(txt)
        {
            alert ("JavaScript 'showAlert': called from " + txt);
        }

   var params =
        {
                    domwin: window,
                        domdoc: document,
                        serverhost: "javaweb.eng.sun.com"
        };

   java.lang.System.out.println("Starting jotest.html");

</script>
</body>
</html>

Java code:
import netscape.javascript.*;

public class Cherokee
{
    JSObject win = null;

        //-----------------------------------------------------------------
        // Constructor
        //-----------------------------------------------------------------

    public Cherokee(String txt)
        {
           System.out.println("*** Cherokee constructor: ***" + txt);
    }


    //--------------------------------------------------------------------
        // Public Methods
        //--------------------------------------------------------------------

    public void load(JSObject params)
    {
        JSObject jso;

        System.out.println("*** cherokee.load: Start of method ***");

        if (params ==  null) {
                System.out.println("params is null");
        } else {
                System.out.println("calling params.getMember()");
                win = (JSObject) params.getMember("domwin");
                if (win == null) {
                        System.out.println("*** cherokee.load: win is null ***"
);
                } else {
                        System.out.println("*** cherokee.load: win is not null
***");
                }
        }
        System.out.println("*** cherokee.load: End of method ***");
    }
}


Sorry Joe, the patch is complete. There's no need to stop calling 
StartupLiveConnect() in nsJSEnvironment::nsJSEnvironment(), because Java 
initializes only when LiveConnect actually tries to resolve a package into a 
class. Please try running with only the last patch in your tree. I ran with just 
that on Linux and things work for me.

Patrick, you are right about no need to remove StartupLiveConnect. I tried it,
and that seemed working fine.
But the problem of my test case above was still there: with the patch, clicking
the "Call load()" button did not call the load method, unless bringing up the
Java console first, which loaded Java plugins. Without the patch, clicking the
button invoked the call method. Is that a problem? Did you tested it with a case
that did not have an applet tag, something similar to the Oracle case in 60018?
I tested with the URL "javascript:java.lang.System" which fires up Java. Does 
this simple URL work for you? I will try your test case, which may be failing for 
other reasons. Would you please provide a review for this patch?

Patrick, can you please attach another diff?  I can't get this one to apply:

D:\Projects\trunk\mozilla\js\src\liveconnect>patch -i 26516.diff jsj.c
patch -i 26516.diff jsj.c
patch unexpectedly ends in middle of line
patch: **** Only garbage was found in the patch input.

I tried the url on my SOlaris, and I saw similar problem: if I tried to launch
the url without Java plugin loaded first, nothing showed up; but if I opened the
Java console first and then launch the url, I saw "[JavaClass java.lang.System]"
printed on the page. I am going to tried on another trunk build on Solaris and
Linux, and see how it goes.
To edburns: Patch http://bugzilla.mozilla.org/showattachment.cgi?attach_id=30892
has a weired format. Solution for unix users:
-- snip --
% cat xxx.diff | tr "[\r]" "[\n]" >yyy.diff
gisburn@castor/home/gisburn/tmp/moz% gpatch -p0 --dry-run <yyy.diff 
patching file jsj.c
Hunk #1 FAILED at 449.
Hunk #2 succeeded at 468 with fuzz 2.
Hunk #3 succeeded at 948 (offset 253 lines).
1 out of 3 hunks FAILED -- saving rejects to file jsj.c.rej
-- snip --

I've tried this on an 11pm last night Win32 trunk clobber build and I find that 
the plugins module is loaded at startup.  However, this is the plugin code.  Is 
your diff supposed to prevent all java related initilization, or only 
liveconnect related initialization?

nsPluginHostImpl ctor
plugins at: D:\Projects\trunk\mozilla\dist\WIN32_D.OBJ\bin\plugins
plugins at: C:\Program Files\Opera\Program\Plugins
For application/x-java-vm found plugin 
D:\Projects\trunk\mozilla\dist\WIN32_D.OBJ\bin\plugins\NPOJI600.dll


Debugging further, I find that on win32, the nsJVMManager::StartupJVM() gets 
called even with your patch applied.

Here's the stack trace:

nsJVMManager::StartupJVM() line 573
nsJVMManager::MaybeStartupLiveConnect() line 780 + 20 bytes
nsJVMManager::StartupLiveConnect(nsJVMManager * const 0x0199fa58, JSRuntime * 
0x010579c8, int & 0) line 128 + 11 bytes
nsJSEnvironment::nsJSEnvironment() line 1505 + 49 bytes
nsJSEnvironment::GetScriptingEnvironment() line 1446 + 27 bytes
NS_CreateScriptContext(nsIScriptGlobalObject * 0x0197ec90, nsIScriptContext * * 
0x01979240) line 1545 + 5 bytes
nsDocShell::EnsureScriptEnvironment(nsDocShell * const 0x01979190) line 4439 + 
50 bytes
nsWebShell::GetInterface(nsWebShell * const 0x019791b4, const nsID & {...}, 
void * * 0x0012fbd4) line 329 + 19 bytes
nsGetInterface::operator()(const nsID & {...}, void * * 0x0012fbd4) line 37 + 
31 bytes
nsCOMPtr<nsIDOMWindowInternal>::assign_from_helper(const nsCOMPtr_helper & 
{...}, const nsID & {...}) line 970 + 18 bytes
nsCOMPtr<nsIDOMWindowInternal>::nsCOMPtr<nsIDOMWindowInternal>(const 
nsCOMPtr_helper & {...}) line 552
nsAppShellService::GetHiddenWindowAndJSContext(nsAppShellService * const 
0x00aeb350, nsIDOMWindowInternal * * 0x0012fc7c, JSContext * * 0x0012fc80) line 
713 + 32 bytes
nsAppShellService::SetXPConnectSafeContext() line 177 + 40 bytes
nsAppShellService::CreateHiddenWindow(nsAppShellService * const 0x00aeb350) 
line 248
main1(int 2, char * * 0x00a359b0, nsISupports * 0x00000000) line 988
main(int 2, char * * 0x00a359b0) line 1300 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77f1ba3c()

I tried on the load from the tip of the trunk on Solaris (built last night) and
Linux (built today), found similar result:
The Java JVM was started at startup (StartupJVM got called), and all the MIME
types got registered. 

On the other hand, my previous testing was done on an OEM load on Solaris. In
that case, with the patch, Java JVM was NOT started at startup time, and the
url, "javascript:java.lang.System", would not work unless I opened Java console
(which started JVM and loaded plugins' MIME types) first.
I concur, nsJVMManager::StartupJVM() does get called still, but, if I set a 
breakpoint on the MRJ plugin's MRJPlugin::StartupJVM() method, it doesn't get 
called until I actually do something with Java, such as a javascript: URL that 
references java.lang.System. Does the Sun Java plugin startup Java 
unconditionally or does it wait until its nsIJVMPlugin::StartupJVM() method is 
called?

Patrick, that patch looks ok to me, barring calls to these functions that happen
even if the JavaVM has not been created/attached:

JSJ_DisconnectFromJavaVM
JSJ_AttachCurrentThreadToJava
JSJ_DetachCurrentThreadFromJava

Should these have null defenses against java_vm anyway? 
r/sr=brendan@mozilla.org modulo that.

/be
Yeap, java_vm on Solaris would not be started till the first LiveConnect call.
The patch seemed doing what it suppose to do.

ra=edburns.
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Is it possible that this fix causes a crash when going to pages with applets
when the plugin is not installed and when "Java Enabled" is checked in the
preferences? Should I file a new bug about this?
Seen by two people on linux, CVS build from one hour ago (04/19)
When I tested the patch, I saw the crash with or without the patch. I don't
think the crash is related to the patch. There is a bug about the crash leaving
an applet page, and the bug number is 75070.
*** Bug 78220 has been marked as a duplicate of this bug. ***
Blocks: 78220
verified that nsJVMManager::StartupJVM() does not get called on startup anymore 
on trunk builds.
Status: RESOLVED → VERIFIED
wooohooo ? anyone still working on this ? atleast update the target milestone
umm ... Michael ... this bug is already fixed
ummm, just testing if you all watch out carefully *doh* *blush*
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: