Time to put a stop to Thread.stop?

Peter Levart peter.levart at gmail.com
Thu May 16 08:57:53 UTC 2013

On 05/16/2013 09:44 AM, Mario Torre wrote:
> 2013/5/16 David Holmes <david.holmes at oracle.com>:
>>> +1
>>> I think it should also blow at runtime unless people passes some fancy
>>> argument (like -XX:recallRetired :), this way is easier for people to
>>> fix their code, or, in case they can't, do workaround it.
>> Interesting suggestions but I for one do not think that after 15 years of
>> deprecation we need to go to such lengths to keep stop(Throwable) on
>> life-support - it is @Deceased in my opinion :)
> Hi David,
> In fact, I fully agree for Thread.stop we should probably just do as
> you suggest and kill it :) but my interest shifted to the @Retired
> annotation which could be a nice general thing to have (Thread.stop
> could actually be a test case for it).
> Ideally, by Java 9, we could go through most of the @Deprecated and
> convert them to @Retired and give one platform lifetime to make people
> adjust their code. Java 10 could be finally free of all those ancient
> vestiges of a glorious past :)
> Cheers,
> Mario


Since developers are by definition lazy (at least the Perl ones ;-), 
aren't you afraid that in order to move from JDK N to JDK N+1, they 
might "quickly fix" references to @Retired methods by using reflection?

Regards, Peter

> --
> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
> Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF
> IcedRobot: www.icedrobot.org
> Proud GNU Classpath developer: http://www.classpath.org/
> Read About us at: http://planet.classpath.org
> OpenJDK: http://openjdk.java.net/projects/caciocavallo/
> Please, support open standards:
> http://endsoftpatents.org/

More information about the core-libs-dev mailing list