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.ri...@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
