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
