Win a copy of The Journey To Enterprise Agility this week in the Agile and Other Processes forum! And see the welcome thread for 20% off.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Jeanne Boyarsky
  • Liutauras Vilda
  • Campbell Ritchie
  • Tim Cooke
  • Bear Bibeault
Sheriffs:
  • Paul Clapham
  • Junilu Lacar
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Ganesh Patekar
  • Tim Moores
  • Pete Letkeman
  • Stephan van Hulst
Bartenders:
  • Carey Brown
  • Tim Holloway
  • Joe Ess

Deprecation in Java  RSS feed

 
Greenhorn
Posts: 3
2
  • Likes 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am a researcher looking into the deprecation mechanism of Java. We found that most developers when they encounter a deprecated feature, prefer not to react to it. That is they do not remove the reference to the deprecated feature and replace it with the recommended replacement. I was wondering as to why this might be the case? Is it a deficiency in the deprecation mechanism itself? Or do developers not have time. It would be awesome if some of the experienced heads here could fill out our survey to answer this: http://www.surveygizmo.com/s3/3754964/Deprecation-reaction
 
Marshal
Posts: 4453
284
Clojure IntelliJ IDE Java
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Done. It'd be great if you'd come back and share your findings with us.
 
Marshal
Posts: 59681
187
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the Ranch

Find a copy of Object Oriented Software Construction by Bertrand Meyer. Go through that and look for the OBSOLETE keyword. Meyer says you can mark a feature as obsolescent and then remove it six months later. I interpret that as meaning your app which has worked nicely for ten years stops working without warning or explanation after an upgrade. If you look at this thread from January last year, you will find a much better explanation from Tim Holloway.

In that old thread, Tim Holloway wrote:Deprecation allows the vendor to gracefully remove functionality so that instead of a fatal compile error, you get a deprecation warning, can safely put the amended app into production and can then update the app's source code at leisure, rather than in a flustered panic. OK, we all know that "leisure" means never, but still, the idea is sound.

I think OBSOLETE is the right keyword.
 
Ranch Hand
Posts: 50
3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Until now, even though the API were marked as deprecated, they were never removed. So, developers were relaxed and comfortable to let things run the way they are and not go to the trouble of replacing them. But now , things have changed in Java as well with Java 9. See this JEP http://openjdk.java.net/jeps/277 . Now, the deprecated API which are marked with forRemoval = true, will be removed in the next major release. So, the developers will be forced to be attentive and replace them.
 
Saloon Keeper
Posts: 4678
117
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

developers were relaxed and comfortable to let things run the way they are and not go to the trouble of replacing them.


That is troubling, though. The javadocs of quite a few deprecated APIs make it very clear that those APIs are deficient or downright buggy. Makes one wonder what else such developers don't pay attention to.
 
Saloon Keeper
Posts: 9118
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm completing the survey now. I find it hard to answer some of the Agree/Disagree questions, because just selecting the option leaves out a lot of information. For instance, when asked whether I "Replace the deprecated call with functionality from the Java Development Kit (JDK)", I entered "Ocassionally". To me, that appears that I will often prefer the recommended alternative provided by the third party library. In reality, I will prefer to replace (non-)deprecated functionality from a third party library with that from the JDK when I have the opportunity, thereby reducing the amount of dependencies I have. This opportunity simply doesn't arrive so often. I find these types of questions work better if there's a field to explain the choice.

A silly question is: "I did not know/was not aware of the deprecation (lack of tools or documentation to make me aware)". How can I answer that question, if I wasn't aware of the deprecation?

Anyway, just completed it, good luck with the study.
 
Stephan van Hulst
Saloon Keeper
Posts: 9118
172
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A good reason for removing deprecated API usage: I don't like the strikethroughs that my editor shows
 
Tim Cooke
Marshal
Posts: 4453
284
Clojure IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How's it going with the survey John?
 
Sheriff
Posts: 23640
48
Eclipse IDE Firefox Browser MySQL Database
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There's another reason for disregarding deprecation warnings which wasn't mentioned in the questionnaire and hasn't been mentioned here: Conservative worldview.

Some of you may remember when Java 2 came out and it had this brand-new comprehensive Collections framework. It was strongly suggested that you should stop using Vector and start using ArrayList instead. (Note: Vector still isn't marked as Deprecated because it's widely used in Swing code.) There were furious threads on the then Sun forum about why it was actually better to use Vector than ArrayList -- many of the arguments used there reminded me of the arguments against seatbelts when they were first made mandatory. ("It messes up my clothing." "I can just put my hands up on the dashboard if we're going to crash." "It's safer to be thrown out of the car.")

Yes, some people just don't like change. (Why they go into programming I don't know.)
 
Tim Cooke
Marshal
Posts: 4453
284
Clojure IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This survey must be finished by now, surely. Can you share the analysis with us John?
 
John Brady
Greenhorn
Posts: 3
2
  • Likes 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All, sorry for the delay with the results. One of the things we found was that predominantly developers do not react to deprecation due to the cost involved with reacting. Essentially, developers do not think it is worth their time to take deprecation seriously. This is something that the Java JDK developers also noticed. Another major reason for not reacting is that the alternative provided was not suitable or too convoluted to use. Which means that API producers have a lot to improve on as well. The strangest finding from the survey was that developers all said that they actually react to deprecation, which GitHub data (mined on an ultra large scale) says otherwise. This is something that we can put down to social desirability bias, where developers want to appear fully in line with programming norms. Overall, we see that the deprecation feature has a lot of issues even now, and more clear communication is needed from API producers regarding the future of deprecated features. And the warnings need to be made more severe/explicit so that consumers know that there is some danger in not reacting and that technical debt in their project will only grow over time.
 
Tim Cooke
Marshal
Posts: 4453
284
Clojure IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for reporting back John. I gave you a cow for not leaving us hanging

What do you intend to do with your findings?
 
John Brady
Greenhorn
Posts: 3
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Given that I work in academia, write a paper ! But even more importantly, we have to ask the question what can API producers do to improve the situation? What can Java do to improve the situation? And what role does code documentation/tooling and education play in all of this?
 
Stephan van Hulst
Saloon Keeper
Posts: 9118
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think a large part of it is culture. I've noticed that because of my Java background, I value backwards compatibility a lot, even for major versions. Maybe developers should be less afraid of breaking backwards compatibility if it means they can properly dispose of deprecated APIs. This will also drive other developers to react to deprecation more promptly. The problem I see with this is managers complaining.
 
Campbell Ritchie
Marshal
Posts: 59681
187
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Was it you who said that backwards compatibility is one of the attractions of Java®? No, I see it was Tim H.
What if you have a Swing app which has been running happily for nearly twenty years using the show() and hide() methods? What if whoever wrote the app has left/retired/died? What if Oracle notice these long‑deprecated methods and remove them altogether from JDK19.9? I know Bertrand Meyer says that is what should happen (Object‑Oriented Software Construction 2/e 1997, pages 802‑803). But to your users it means code suddenly stops working after an update and they don't know why.
 
Stephan van Hulst
Saloon Keeper
Posts: 9118
172
  • Likes 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There's a difference between binary compatibility and source compatibility. Making it so you can't recompile old code if you update the source version is different from making it so you can't run old libraries if you update the target version.
 
Campbell Ritchie
Marshal
Posts: 59681
187
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If that is what removal means, then it is all right. You shouldn't want to recompile old code without updating it. And if you are updating the old code, you should be removing any deprecated API.
 
Bartender
Posts: 19655
92
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Are my ears burning?

I've been on record as saying that you should remove deprecated resources and methods from your code after a decent interval (say 6 months or so), but one of the most famous deprecations of all is the java.util.Date(m, d, y) constructor. This has been deprecated since about Java 2, and yet it's still around.

It was deprecated because A) it's locale-ignorant and B) assumes that the natural way of stating a date is US form.

However, it's also a quick and dirty way to build a date constant. And it's been used in enough places that if it was actually removed, half the Internet would probably break, not to mention innumerable services and applications. So deprecated or not, I'm not expecting to see it get yanked. Still, you do get put on notice that you're being sloppy.

So while I recommend pulling deprecated stuff between major versions of in-house stuff (and a lot of the external 3d party libraries), I have to confess that best practices are a little different when you are the Supreme Ultimate source for Java.
 
Campbell Ritchie
Marshal
Posts: 59681
187
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry, I hadn't noticed that post earlier.
If I had my way, the whole Date and Calendar classes would be consigned to cyber‑Hades now that something decent has been introduced instead.
But if deprecation means that new code won't compile, all well and good. Using it is even worse than using StringTokenizer which has been described as only there to support legacy code since Java1.4. At least Tokenizer was pleasant to use.
 
Rancher
Posts: 1017
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
System.getenv used to be deprecated for a while but has been undeprecated and alive and kicking ever since :-)
 
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
when a class or method is deprecated, it means that the class or method is no longer considered important. It is so unimportant, in fact, that it should no longer be used at all, as it might well cease to exist in the future. The need for deprecation comes about because as a class evolves, its API changes. Methods are renamed for consistency. New and better methods are added.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!