Time to retire System.runFinalizersOnExit?

Mandy Chung mandy.chung at oracle.com
Thu Jan 29 03:43:18 UTC 2015


On 1/28/2015 5:36 PM, Stuart Marks wrote:
> On 1/28/15 7:07 AM, Alan Bateman wrote:
>> On 27/01/2015 04:37, Mandy Chung wrote:
>>> System.runFinalizationOnExit has been deprecated since 1998 (JDK 1.2)
>>> and this method is inherently unsafe.  I am thinking to propose this 
>>> method
>>> in JDK 9 to throw UnsupportedOperationException.
>>>
>>> I believe it's rare for existing applications using 
>>> System.runFinalizationOnExit.
>>> My analysis on Maven Central ~315K artifacts that show about ~15 unique
>>> artifacts calling System.runFinalizationOnExit while they all come from
>>> only 5 classes.
>>>
>>> Any thought/feedback?
>> It's broken in other ways beyond what is in the @deprecated note so I 
>> don't
>> think it's much of a loss to finally disable it. I don't know if you 
>> have come
>> up with candidate wording to replace the existing wording but having it
>> reference the shutdown hooks and the ref API might be useful.
>
> As I understand it, it's not System.runFinalizationOnExit() *itself* 
> that's unsafe, it's the act of running finalizers on still-reachable 
> objects at exit time that's unsafe.
>
> A potential alternative would thus be to change the method call to be 
> a no-op, and just disable the running of finalizers at exit time. This 
> would let us remove the unsafe behavior, and it avoids forcing people 
> to recompile code that calls rFOE.
>
> Clearly, this would be a silent change in behavior, which is usually 
> something we want to avoid. But the calling code can't tell the 
> difference anyway. This is to be traded off against potential forced 
> recompiles, which don't add much value beyond notification, but which 
> may be inconvenient or even impractical in some cases. I'm not sure of 
> the right tradeoff here.

Throwing UOE is intentional so that applications depending on existing 
behavior will be modified not to use this deprecated method.   Making it 
a no-op makes it harder to diagnose for applications depending on the 
finalizers to be invoked on exit to free resources.  I opt to throw UOE 
(or remove the method that will leave it for another discussion some 
other day).

Mandy




More information about the core-libs-dev mailing list