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?

I'm basically looking for an install process that goes much like the
typical Adobe Flash Player install.

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

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?

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.

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.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to