Time to put a stop to Thread.stop?

[David Holmes]

On 16/05/2013 12:36 AM, Mario Torre wrote:
> 2013/5/15 Remi Forax <forax at univ-mlv.fr>:
>> On 05/15/2013 10:39 AM, Martin Desruisseaux wrote:
>>>
>>> Le 15/05/13 10:05, David Holmes a écrit :
>>>>
>>>> There is a huge difference between blowing away a complete process with
>>>> kill and having a single thread starting to propagate an async exception,
>>>> unwinding its stack and executing finally blocks with completely broken
>>>> state invariants.
>>>
>>>
>>> Given the risk, what about a mechanism similar to the one which currently
>>> hides the Sun internal packages from the compilation phase but not yet from
>>> the runtime phase? Would it be acceptable to have 'javac' and 'javadoc'
>>> woking as if the 'Thread.stop(Throwable)' method did not existed anymore,
>>> while having the method still working (for now) at runtime for existing
>>> libraries? Maybe with an annotation yet stronger than @Deprecated.
>>>
>>>      Martin
>>>
>>
>> yes, I propose @Retired.
>
> +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 :)

Cheers,
David
-----

> Cheers,
> Mario
>
> --
> 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/
>