I think he is arguing that probably many people who do not subscribe to this
mailing list will have overridden Thread.clone() with an implementation that
does not call super.clone(), simply because the "standard" name for methods
that copy an object was "clone". And that you will be breaking all of this
perfectly valid code simply because you don't like it. Crusades against ugly
code (that break existing applications and libraries) don't do the language
much service when perhaps even a majority of applications in various
industries are written "badly". Even the smartest make bad decisions when
learning, and there are plenty of people who aren't the smartest to carry on
when those have figured out not to. Plenty of such projects are then
"maintained" (i.e. left alone as much as possible) by people who have never
or rarely seen the code base, and inflicting this kind of problem on them is
unkind at best.
I think people on this and similar mailing lists might sometimes forget that
the majority of users *don't subscribe to it*, and that these people need to
be catered to just as much as those that do. And that the people who *don't
*subscribe *just may *be the people who are more likely to have made these
kinds of errors, and not understand why their previously functional code now
doesn't work with a new release of Java.
On 17 August 2010 11:07, David Holmes <david.hol...@oracle.com> wrote:
> Bruce Chapman said the following on 08/17/10 19:17:
>
> In the early days of my climb up the java learning curve, well before
>> much body of commonly understood best practice evolved, there are many
>> things which in hindsight are regrettable. Here's two
>>
>> 1./ Our highly threaded app had many classes that extended Thread
>> instead of the (now) wiser "implements Runnable"
>>
>
> Well Doug Lea and I were touting this since 1996! If you want to define
> some work define a Runnable, if you want to define a "worker" then extend
> Thread. :)
>
>
> 2./ I thought clone() and Cloneable was the right way to get a 'copy
>> constructor' (it was in the JDK, it must be best practice - right?)
>>
>
> Yes that one is best practice right along-side destructors, oops I mean
> finalizers :)
>
>
> Therefore there is a reasonable chance that in that (once familiar yet
>> minuscule) body of code from a previous millennium, there is a class
>> that extends Thread and is cloned using a clone() method.
>>
>> You might not find it in more recent code, but these were once commonish
>> idioms, till Josh corrected us with Effective Java. Some of that code
>> may still be running. Don't break it.
>>
>
> Well I contend it's already broken if it is cloning a thread but that aside
> ...
>
> ... You seem to be advocating for not making this change at all, as opposed
> to arguing for or against clone() being final? But we either have to
> disallow cloning or give it meaningful semantics - and the latter isn't
> going to happen.
>
> David
>
>
>
>> Bruce
>>
>>
>> David Holmes wrote:
>>
>>> Jeroen Frijters said the following on 08/17/10 14:11:
>>>
>>>> David Holmes wrote:
>>>>
>>>>> Fortunately, as Brian stated, compatibility is not an end unto itself
>>>>> here and we often do have documented incompatibilities across major
>>>>> releases. In this case there is far more harm, in my opinion, leaving
>>>>> the possibility of people trying to clone threads than there is in
>>>>> breaking a hypothetical program that is unlikely to be functioning
>>>>> correctly anyway. Thread should never have been cloneable in any way -
>>>>> the fact that this has flown under the radar for so long is a strong
>>>>> indicator that nobody actually does this in practice (else they would
>>>>> have complained that it didn't work).
>>>>>
>>>>
>>>> I really don't understand your position. It clearly doesn't make sense
>>>> to call Object.clone() on a Thread, but you can have a perfectly safe
>>>> clone() on a Thread subclass:
>>>>
>>>> public final MyCloneableThread extends Thread {
>>>> public Object clone() {
>>>> return new MyCloneableThread();
>>>> }
>>>> }
>>>>
>>>
>>> I assume you really meant something like "new MyCloneableThread(this)" to
>>> actually get a copy. You can do that, but:
>>>
>>> a) the above gives you nothing that the constructor alone could not
>>> achieve
>>> b) the above is only valid in a final class (as used), or if documented
>>> explicitly so that subclasses know that they can not use super.clone()
>>>
>>> If we prevent a Thread subclass from calling super.clone() but still
>>> allow the subclass to override clone() then we will need to document that
>>> they can only use a construction-based clone technique, and that all further
>>> subclasses will also be constrained to that technique.
>>>
>>> I don't see the point in going to such lengths when our message is a very
>>> simple "Thread is not cloneable - get over it, move on". Let's close the
>>> door completely, not leave it ajar. I/we only want to set right what should
>>> not have been done wrong in the first place.
>>>
>>> On the other hand, there is no reason to make clone() in Thread final
>>>> other than some vague notion that you want to prevent people from writing
>>>> new code like the above, but given that Java is an "old" and stable
>>>> platform
>>>> that argument doesn't carry much weight either.
>>>>
>>>> BTW, from a security standpoint, overriding clone doesn't help. An
>>>> attacker can simply create a Thread subclass that doesn't have the
>>>> ACC_SUPER
>>>> flag set and that class will be able to call Object.clone() just fine.
>>>>
>>>
>>> I'm not quite sure exactly what you mean, but if that is the case then
>>> someone should file a bug report.
>>>
>>> Cheers,
>>> David
>>>
>>> Regards,
>>>> Jeroen
>>>>
>>>>
>>>
>>
>>
