Time to retire System.runFinalizersOnExit?

[Peter Levart]

On 01/29/2015 04:43 AM, Mandy Chung wrote:
>
> 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
>

Wouldn't it be possible to make the method safe?

Finalizers are usually run against un-reachable objects. If the Shutdown 
sequence made sure all threads are stopped except the thread executing 
Shutdown sequence, then all objects would become effectively unreachable 
(except being reachable from shutdown thread that can assume the role of 
finalizer thread and run the finalizers...).

Peter