Tim Ellison wrote:
Geir Magnusson Jr. wrote:
Tim Ellison wrote:
Geir Magnusson Jr. wrote:
So VMs aren't embeddable.
How so? *Any* thread in an app can potentially call an OS's exit() and
bring down the app, so why are you distinguishing the thread that
happens to be running Java code?
Becuase I'm reading the spec which says that System.exit() exits the VM,
not the process, but the behavior is that current impls kill the process.
I was responding to your "embeddable" comment. I agree that the spec
says that System.exit() will terminate the VM; it does not say that it
will terminate the process. However, it's a pretty big compatibility
issue so I suggest we do likewise.
Maybe we can offer a flag for people that want to truly embed the VM...
If you don't want the Java app to call System.exit() then you can set up
a security manager to prevent it. It will then be required to unwind
nicely to get out, and the VM will terminate when there are no
non-daemon threads etc etc.
But there's nothing wrong with System.exit() just killing the VM. So
sure, you can revoke the exitVM perm, but also in the event when you
want it to happen, I think there's nothing wrong with letting it, and
just having the VM exit.
No, we have to be compatible here. There may be apps that use libraries
that fork worker threads that are nothing to do with Java -- they will
'hang' (i.e. continue running) if we don't behave like other
implementations.
We will be compatible. But there's no harm in offering a configuration
option that lets people who embed make a *conscious* decision to use it
'correctly'.
geir
