|
I think it depends what are you deprecating.
If it's just a matter of a simple "instead of using this method, use that other method", I would tend to agree with the people that say to just remove it from the javadocs, but leave it in the runtime.
There is a much broader interpretation, though. Say we want to evolve a library, such as java.util.Date, or make Swing use Collections. How do we transition? Shall we leave the whole library there, for backward compatibility (do we actually deprecate it)? For these kinds of things, I agree with the people that support the module system: just say you depend on Java 7 instead of Java 8.
IMHO, the latter case is much more interesting. There are already enough cases in Java where I have to give an "historical perspective" to junior programmers when I want them to really understand why things are that way... I think that's where Java shows its signs of age (the evolution of io, collections, Swing, Thread, Generics, ...), not the fact that we have a few deprecated methods here and there... |
java.net RSS Feeds
