RFR 9: 8138696 : java.lang.ref.Cleaner (original) (raw)

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

Roger Riggs roger.riggs at oracle.com
Thu Oct 15 13:03:00 UTC 2015

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

More information about the core-libs-dev mailing list