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

Reply via email to