Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

!!!!!! Deprecation in Java  RSS feed

 
John Brady
Greenhorn
Posts: 1
  • Likes 2
  • 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
 
Tim Cooke
Marshal
Posts: 3838
221
Clojure IntelliJ IDE Java
  • Likes 1
  • 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.
 
Campbell Ritchie
Sheriff
Posts: 55330
157
  • 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.
 
Pallavi Sadit
Ranch Hand
Posts: 48
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.
 
Tim Moores
Saloon Keeper
Posts: 3829
79
  • 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.
 
Stephan van Hulst
Saloon Keeper
Posts: 7709
141
  • 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: 7709
141
  • 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: 3838
221
Clojure IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How's it going with the survey John?
 
Paul Clapham
Sheriff
Posts: 22374
42
Eclipse IDE Firefox Browser MySQL Database
  • 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.)
 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!