Take a quick flip through the Java 7 JavaDoc, and you’ll notice that a few key methods of the java.util.Date class have been deprecated. Use the Date(String) constructor or the getMinutes() method, and you’ll be looking at a swift slap on the wrist by the Java 7 compiler.
But here’s the thing: these methods have been deprecated since Java moved beyond version 1.1 Isn’t there some point where deprecated methods need to get removed from the language? The question itself is rhetorical, as clearly there doesn’t seem to be any impetus to flush the bowels of the Java API.
Which brings us to SpringSource, and their clearly haphazard approach to actually removing methods from their API within a year or two after deprecating them. Clearly they’re doing deprecation wrong.
"Generally, with deprecation, we do take a more proactive view than Java as a whole. Basically it seems that the view of Java is that deprecation means nothing, whereas our view of deprecation is that if you deprecate something, you take it out in the next major release." Says Rod Johnson, the creator of the Spring framework. "I think it’s very important that as you add some stuff, you’ve got to remove some stuff, otherwise it just becomes confusing."
Well, Rod’s assertion seems to make logical sense, but clearly SpringSource is swimming against the current on this one. Release after release, developers young and old are being taught the true definition of ‘deprecation.’ Basically, it means nothing. Enjoy coding up your new java.util.Date(String) objects.