harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@gmail.com>
Subject Re: [drlvm][shutdown] How to cleanup resources safely?
Date Tue, 21 Nov 2006 14:33:30 GMT
Alexey Varlamov wrote:
> 2006/11/21, Evgueni Brevnov <evgueni.brevnov@gmail.com>:
>> On 11/21/06, Alexey Varlamov <alexey.v.varlamov@gmail.com> wrote:
>> > 2006/11/21, Tim Ellison <t.p.ellison@gmail.com>:
>> > > Evgueni Brevnov wrote:
>> > > > On 11/21/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
>> > > >>
>> > > >> Evgueni Brevnov wrote:
>> > > >> >
>> > > >> > As it was discussed earlier (and I think agreed) the 
>> System.exit()
>> > > >> > should terminate entire process the VM is running in right

>> after it
>> > > >> > executed shutdown hooks and finalizes.
>> > > >>
>> > > >> I don't think so.  How could you embed the VM in another program?
>> > > >
>> > > > My initial understanding was that System.exit() shouldn't terminate
>> > > > the process. But the experiments proved the opposite. AFAIU if you
>> > > > want to embed the application then it should not call 
>> System.exit().
>> > >
>> > > I was surprised to see the results of you experiment too -- I'd have
>> > > failed that Java pop-quiz question!
>> > >
>> > > > I don't see any problems to extend the proposal to the case of
>> > > > System.exit() so that the process will not be stopped. But, do 
>> we want
>> > > > such incompatibility with RI?
>> > >
>> > > No, we can't change that -- if people expect the program to exit() 
>> it we
>> > > will see hangs everywhere.  As somebody (I forget) wrote at the 
>> time, it
>> > > becomes the responsibility of the app to set the security policy to
>> > > disallow exit() if they expect the Process to live on.
>> >
>> > Policy would not help here actually, javadoc for
>> > java.lang.RuntimePermission says:
>> > "The "exitVM.*" permission is automatically granted to all code loaded
>> > from the application class path, thus enabling applications to
>> > terminate themselves."
>> > And normally it is hardly possible to bypass the default system
>> > classloader, one need to hack standard classloading delegation
>> > mechanism.
>>
>> Is there any way to influence default policy?
> AFAIU this not a policy, just hardcoded static permissions granted by
> the system classloader when a class is defined - much like any
> URLClassLoader grants access to the class own URL.

Do you mean that a java applet may bring down a browser process? I had 
an impression that applets have a very strict set of permissions, like 
no access to the disk, etc. Do they have exit still allowed?

-- 
Gregory


Mime
View raw message