Time to put a stop to Thread.stop?
david.holmes at oracle.com
Thu May 16 04:15:35 UTC 2013
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.
>> yes, I propose @Retired.
> 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 :)
> 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:
More information about the core-libs-dev