On 05/16/2013 09:44 AM, Mario Torre wrote:
2013/5/16 David Holmes <david.hol...@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
Hi,
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/
