RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization
roger.riggs at oracle.com
Thu Oct 15 13:03:00 UTC 2015
I think this warrants some discussion related to the normal deprecation
If there is specified behavior related to finalize, then the behavior
has to be replicated
using the Cleaner to ensure backward compatibility. It is a spec change
(at least a
documentation change) and may move from the finalize method to the class
Since finalize is an overridden method, removing a particular override
remove the method. There is no issue with source compatibility. I'll
check binary compatibility that the VM when it sees a call to a specific
finalize method that it will search up for the super method. I think
this is the case.
If it is decided that the finalize method overrides need to follow the
2 release deprecation cycle there is not much of a down side. There is an
optimization in the VM that looks for empty finalize methods. Only if a
has at least one non-empty finalize method does the overhead for a
reference kick in.
yes, finalize methods in non-public classes can be removed.
BTW, I expect there are cases where it is not practical or urgent to replace
the finalizers and they will stay the same, perhaps indefinitely.
On 10/15/15 6:47 AM, Chris Hegarty wrote:
> On 14 Oct 2015, at 18:43, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>> Hi Alan, Mandy,
>> I looked at a few of the many uses of finalize and the likely changes.
>> The zip Inflater and Deflater are relatively simple cases.
>> Some finalizers are not used and can be removed.
> It is not immediately clear to me. Are you saying that some
> finalize() methods, like the ones on Inflater and Deflater,
> are part of Java SE spec and should be deprecated in 9,
> then removed in 10. While others, that are just
> implementation, can be removed now?
>> The sun.net.www.MeteredStream example subclasses PhantomCleanable to add the state and cleanup
>> Some of the harder cases will take more time to disentangle the cleanup code.
>> For example, ZipFile, and FileIn/OutputStream (Peter has prototyped this).
>> On 10/14/2015 10:23 AM, Alan Bateman wrote:
>>> On 14/10/2015 15:03, Roger Riggs wrote:
>>>> Hi Alan,
>>>> So any user of the Cleaner can take advantage of the mechanism, for example in a different package or module.
>>>> For example, Netbeans.
>>> Cleaner + Cleanable need to be public of course so maybe we should wait for the examples that extend WeakCleanableRef or cast the Cleanable to a WeakCleanableRef before seeing if this is the right thing or not.
More information about the core-libs-dev