On Sep 6, 2008, at 1:46 PM, RogerV wrote:
> > When I installed the Java 6 1.6.0_10-rcb28 that Google Chrome is > requiring, I didn't see anything new going on in the installation > process. It looked to behave much as prior Java JRE installs. > > When is the optimized web install process going to show up? Or what > does it take to get that to happen if it is already there? You were using the standard installer. For the new optimized one you should use the deployment toolkit which will auto-launch the kernel installer if the javascript detects that Java isn't present. There is some documentation on this already but new docs will come with the final release of update 10. > Also, what about that applet tear-out feature we hear about? I tried > to tear away the applet that appears on this page and nothing happens: > > http://java.com/en/download/help/testvm.xml Draggability must be enabled explicitly by the applet developer. http://java.sun.com/developer/technicalArticles/javase/6u10_applets/ > Too, here's a wee bit of a QA heads-up: > > I was running an Oracle-written java applet in Google Chrome, and at > some point the app froze up. Now that's not so unusual for Oracle > software. However, after I used Google Chrome task manager to kill the > page, and then got out of Google Chrome altogether, the Java process > instances was still around - it got orphaned. I had to use the Windows > taskmanger to kill it explicitly. > > Is there something the Java browser plug-in can do to know when to > take down the Java JVM process it creates under such adverse > circumstances? > > Also, if Google Chrome is a parent process and fully exits (or is > killed), should the Java process go down by sake of being a child > process? What exactly is the relationship there? The point of running out of process is to protect the browser in case the Java applet crashes or hangs, which is exactly what happened. Chrome didn't lock up when the applet froze. Even if the app hadn't frozen, you could have killed the Java process with the task manager and the browser would still be fine. > I understand there's intent to support tearing applets away and let > them start running independently of the browser. That would imply > wanting such an applet to remain running even if the host browser > process goes away. Okay, but perhaps when tearing applets out to run > independently, their own private JVM instance might be spawned. > > All I'm getting at is that in the usual case the Java process should > go away if the host browser process goes away for any reason. It > shouldn't be left as an orphaned process. Seems the way to do that is > make it a dependent child process that is killed automatically by the > system in the event the parent process goes away. This is the usual case. The vm process will shut itself down if the browser closes, unless there are applets which have been dragged out. In general the VM will monitor itself and do a good job of keeping itself resident for speed, and closing itself down when not needed. The reason the VM didn't quit when the browser did is because your applet froze, which is exactly what would have happened if the applet had been a standalone desktop app. This is exactly as it should be. > Well, coordinating these multi-process scenarios and getting them to > behave to the user like a simplistic monolithic app in a single > process, is always an interesting challenge. The trick is to > orchestrate things in such a way that the host operating system will > do the necessary purge or resources (like processes) when things go > badly. Hoping to handle some aspects of adversity in the app software > layer can run into robustness issues. Yep. The new plugin actually has a small headless instance of Java which does run inside the browser. This instance manages all of the other ones (since there are cases when there *should* be more than one worker instance). It will shut down and start up the worker instances as necessary in the most efficient manner. And of course its heuristics will improve over time. - Josh > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
