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. I expect you will get better mileage in lobbying to get the spec changed to reflect reality. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
