On 16/05/2013 12:36 AM, Mario Torre wrote:
2013/5/15 Remi Forax <fo...@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/
