Chris Hegarty wrote:
Thanks everyone for your very valuable feedback.
From what I'm reading there doesn't seem to be a problem with defining
Thread.clone to throw CloneNotSupportedException. OK, that's done. Now
should it be final?
It appears that there is very little value in making clone non-final.
Yes, it will increase compatibility, but not in any overly useful way.
And it seems agreed, previous reason excluded, that the right thing to
do is to remove any doubt about cloning. In light of that I would like
to proceed with the change as originally proposed.
The general evolution policy of the JDK [1] has long been:
1. Don't break binary compatibility (as defined in the Java
Language Specification).
2. Avoid introducing source incompatibilities.
3. Manage behavioral compatibility changes.
Per JLSv3 section 13.4.17 "final Methods," [2]
Changing an instance method that is not final to be final may break
compatibility with existing binaries that depend on the ability to
override the method.
Therefore, adding final to Thread's clone method would be a binary
incompatible change since any (weird, broken) subclasses which override
the clone method would fail to link, which is the definition of binary
compatibility. While there is merit in considering this change, the
default position would be to reject the change as going against the
general evolution policy.
-Joe
[1]
http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html#general_evolution_policy
[2]
http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html#13.4.17
Thanks,
-Chris.
On 15/08/2010 23:22, David Holmes wrote:
Hi Florian,
Florian Weimer said the following on 08/15/10 21:51:
* David Holmes:
tom.haw...@oracle.com said the following on 08/14/10 00:12:
On 13/08/2010 14:58, Chris Hegarty wrote:
protected final Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException();
The final can (and should, IMO) be removed.
Why? What purpose would it serve?
Increased backwards compatibility.
The only thing this would increase compatibility with is if there exists
already a subclass of Thread that overrides clone() to provide
construction-based cloning**. Are you aware of such a use-case? The
postings to the concurrency-interest mailing list and to here are to
solicit feedback regarding any genuine use-cases for this functionality.
So far there have been (as we expected) zero responses regarding actual
use.
The 'final' makes it clear that the programmer should just forget about
clone() when it comes to Thread and any of its subclasses. If we remove
the final then we have to provide additional documentation explaining
the limitations that any override of clone() would encounter.
** Any usage involving super.clone() is already affected by this change
regardless of 'final'.
Cheers,
David Holmes
