RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

[Roger Riggs]

Hi Chris,

I think this warrants some discussion related to the normal deprecation 
practice.

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 
javadoc.

Since finalize is an overridden method, removing a particular override 
does not
remove the method.  There is no issue with source compatibility. I'll 
need to
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 
standard
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 
type
has at least one non-empty finalize method does the overhead for a 
finalizable
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.

Roger


On 10/15/15 6:47 AM, Chris Hegarty wrote:
> Roger,
>
> 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?
>
> -Chris.
>
>> The sun.net.www.MeteredStream example subclasses PhantomCleanable to add the state and cleanup
>> behavior.
>>
>> http://cr.openjdk.java.net/~rriggs/webrev-cleaning-finalizers/
>>
>> Some of the harder cases will take more time to disentangle the cleanup code.
>> For example, ZipFile, and FileIn/OutputStream (Peter has prototyped this).
>>
>> Roger
>>
>>
>>
>> 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.
>>>
>>> -Alan