Fine I give up - no final.
David
Benedict Elliott Smith said the following on 08/17/10 20:31:
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 th
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
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
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 "implemen
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 possibilit
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
Joe Darcy said the following on 08/17/10 06:05:
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.
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 n
Compatibility is not an end unto itself; IMO compatibility with broken
programs is not something we should spend our effort maintaining. I'm +1 on
this change, with final.
On 8/16/2010 5:03 AM, Chris Hegarty wrote:
Thanks everyone for your very valuable feedback.
From what I'm reading there
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 wil
Florian Weimer said the following on 08/15/10 21:51:
Classes storing native pointers must never be cloneable. I hope
having identified all such cases in the JDK, but I can post my scripts
so that others can try to find more instances.
I would not say that "Classes storing native pointers must
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 CloneNotSupportedExc
* Chris Hegarty:
> The issue of whether Threads should be Cloneable came up during the
> discussion of another problem. I talked to David about this and we
> believe there is no value being able to clone a thread, in fact it can
> cause some strange problems. David sent a mail [1] to the
> concurr
* 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 remo
* David Schlosnagle:
> I may be missing something, but if java.lang.Thread.clone() will now
> throw CloneNotSupportedException, how would subtypes properly
> implement Cloneable? If the subtype calls super.clone(),
> CloneNotSupportedException will be thrown. If the subtype calls its
> own constru
On Fri, Aug 13, 2010 at 7:21 PM, David Holmes wrote:
> 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();
>>
>> T
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
On Fri, Aug 13, 2010 at 10:15 AM, Chris Hegarty
wrote:
> OK, so we'll allow subclasses to crate their own clones but disallow access
> to the default Object.clone implementation. I don't have a particular
> problem with this.
>
> -Chris.
I may be missing something, but if java.lang.Thread.clone()
Le 13/08/2010 16:15, Chris Hegarty a écrit :
On 13/08/2010 15:12, tom.haw...@oracle.com wrote:
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.
OK
On 13/08/2010 15:12, tom.haw...@oracle.com wrote:
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.
OK, so we'll allow subclasses to crate their own
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.
Tom
Explicit non-objection :)
On Aug 13, 2010, at 9:58 AM, Chris Hegarty wrote:
>
> The issue of whether Threads should be Cloneable came up during the
> discussion of another problem. I talked to David about this and we believe
> there is no value being able to clone a thread, in fact it can caus
22 matches
Mail list logo
