Time to retire System.runFinalizersOnExit?
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
>>> in JDK 9 to throw UnsupportedOperationException.
>>> I believe it's rare for existing applications using
>>> 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
>> 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
More information about the core-libs-dev