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.

<sarcasm>
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.
</sarcasm>
"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."

<sarcasm>
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.
</sarcasm>

Take a listen to Rod Johnson speaking about the Spring approach to method deprecation.

"...Release after release, developers young and old are being taught the true definition of ‘deprecation.’ Basically, it means nothing...?"

 

And because it means nothing to the Java API in general, Rod, et al, should just fall in step and have it mean nothing to them?  So you can't ever replace an API method, just add them?

Taking them out a "year or two after deprecating them" is haphazard?   Please.... Maybe if James and the boys had eaten their own dog food on this one and come up with a real Date API instead of the SPOS that it is and removed the crap, we wouldn't be having this conversation.

Perhaps you should retitle the submission:

Method deprecation: SpringSource, you're doing it right but because it isn't the way Sunoracle does it, I consider it wrong!

Keeping deprecated stuff forever may also increase release cycle. I know a company where release cycle is 5 years.

To me, it is ok to remove deprecated stuff, as long as 

- the new API introduces some benefit over deprecated one.

- the changes are evolutionary, not revolutionary

- there is a clear and documented migration path.

 

When we talk about deprecation and their removal, we need to understand versioning policies of that product. 

Spring Framework, deprecated many operations in 2.x and they kept it till v2.5.6+. But when they moved to next major release 3.x, they are suppose to remove deprecated methods (as next major release may not be 100% backward compatible.)

Coming to sun sdk, i am assuming, as they still on 1.x branch, there could be same reason. 

 

 

Are you sure you get deprecation right? Just to recap, it works in three steps:

1. API vendor marks methods and classes scheduled for removal with @deprecated.
2. API consumer receives an API release that has new @deprecated advice(s) and replaces use of deprecated methods with other methods.
3. API vendor removes deprecated methods according their deprecation policy (time or release based).

It you do your part at step #2, deprecation will never be a problem. Your application stays operational and the API vendor (and you) get to work with a nice and clean API. It helps to have your build fail on use of deprecated methods so that you have a hard reason to stop using deprecated methods as soon as they marked as such.

Of course, if you ignore @deprecated advice and continue using deprecated methods, sooner or later it will come back and bite you in the a$$ :-)

Regards,

Slava Imeshev

Cacheonix: Reliable Distributed Java Cache

excerpt from "javascript: the good parts" :

[...It is rarely possible for standards committees to remove imperfections from a lagnuage because doing so would cause the breakage of all of the bad programs that depend on thos bad parts ...]

Personnally I never understand sun about deprecation. They also introduced "pruned" with ejb3. What's the point ? Do it or not.

I aggre with all the previous comments. I just will add that i don't understand such title "... you're doing it wrong". Usually, such headline indicates unpromising post (IMHO).

> I aggre with all the previous comments. I just will add that i don't understand such title "... you're

> doing it wrong". Usually, such headline indicates unpromising post (IMHO).

It's just TSS's new strategy for getting our attention :-)

But actually, it's getting a bit old.

<!-- end of col1 -->

"you take it out in the next major release"

- imho, technically Java 6 and 7 are sort of 1.6 and 1.7, Sun dropped the "1." to make it look cool :]

I have seen a java.xxx or javax.xxx class with deprecated methods with empty body (or just throw an Exception); unfortunately I can not remember which class and package it was. I think Spring's approach is much better, finding incompatibility when compiling is much better than exceptions or unexpected functionality at runtime, don't you agree?

Hi,

I think deprecation means something, and what it means is: "don't use this anymore".

Removing deprecated things or not is a political decision. Springsource may remove deprecations from newer versions since it may give them some room for new consulting/training/etc.

Sun's JDK is a different beast, as the deprecated things still MUST remain in the rt.jar, otherwise, imagine if in order to run an app or applet compiled with Java 1.1, you must have installed an older version of the JRE! it would be ridiculous...you could not run a class compiled with Java 1.1 if you have a JRE v6 installed, and THAT would be worst in terms of market impact than removing it.

Regards,

Gabriel

I think you are wrong. Having deprecated methods around for a long time is bad. They are retained in Java for backward-compatibility. In spring the backward compatibility is not that strict, because it's a framework. If you want your old methods - use an older version of spring.

Java is doing it right, and Spring may be right also.

Java is a laguage, if you remove the deprecated method you might as well destroy 70-90% of all the libraries/tools/utilities that were made using old versions.

if i build an application, using 50 or more libraries, do you think all of them are Java 6 or 7 compliant with the deprication? somewhere in those old but usefull lib use depricated method that when they were coded were not yet depricated, but they remain usefull.

Do you think i could get an updated version of those 50 or so libs with Java 6 or 7 complient?

Java around it build an enourmouse resource around it 80% build over old versions of Java using depricated methods somewhere in the code, do you want to but all of them in the garbage? and destroy Java?

 

Thanks

 

 

 

 

 

I've always read the deprecation flag in Java to mean: you shouldn't be using this because its behaviour might not be what you expect or is sometimes wrong, but we'll leave it here for compatibility reasons

Oh,  I hate it when this impersonal medium of online text eats up all of the sarcasm I was attempting to pepper into the post.

Clearly 'deprecation' needs to mean something. It just seems crazy that after all these years that those methods deprecated so many years ago are still in the API, and people are still calling new java.util.Date. 

It's interesting to see both the differing opinions on what 'deprecated' means, along with the assertion that since we're still on the 1.x branch, there is no reason to remove them. Interesting.