wood burning stoves 2.0*
The moose likes Features new in Java 7 and the fly likes Should old stuff be removed from a future Java version? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Java » Features new in Java 7
Bookmark "Should old stuff be removed from a future Java version?" Watch "Should old stuff be removed from a future Java version?" New topic
Author

Should old stuff be removed from a future Java version?

Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14278
    
  21

The standard Java library has a number of deprecated things, and also old classes and interfaces which aren't deprecated but which are obsolete anyway. One of the questions that is asked at Java conferences is the question: Would you want changes in a future version of Java that make it incompatible with older versions?

There are a number of things I can imagine would be removed, for example:

  • The old, legacy collection classes: Vector, Hashtable, Dictionary (superceded by ArrayList and HashMap since Java 1.2)
  • The Enumeration interface (superceded by Iterator since Java 1.2)
  • java.lang.StringBuffer (superceded by StringBuilder since Java 5)
  • java.util.Date and java.util.Calendar; these should be replaced by something like Joda Time (Project ThreeTen)
  • The org.omg.* packages (for CORBA, an ancient RPC technology which almost nobody uses anymore)
  • Marker interfaces such as Serializable and Cloneable (should be replaced by annotations)
  • Replace lists of constants by enums
  • Redesign the ugly implementation for cloning objects (why not have a clone() method in interface Cloneable, instead of having it in Object)

  • There are also language features that I'd like to see removed:

  • Raw types
  • Type erasure
  • Some keywords, for example transient, could be replaced by annotations

  • Would you mind having a future version of Java which is incompatible with older versions, but which gets rid of old junk? What else would you like to see removed or changed?


    Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 8 API documentation
    Winston Gutkowski
    Bartender

    Joined: Mar 17, 2011
    Posts: 8043
        
      22

    Jesper de Jong wrote:Would you mind having a future version of Java which is incompatible with older versions, but which gets rid of old junk? What else would you like to see removed or changed?

    ResultSet - Even after all these years and 200-odd methods later, it's still a piece of sh**. If you absolutely have to have it, at least force suppliers to have it implement Iterator<Row> so that you can actually test if the damn thing has a row without reading it.

    My rant du jour.

    Winston


    Isn't it funny how there's always time and money enough to do it WRONG?
    Articles by Winston can be found here
    Mike Simmons
    Ranch Hand

    Joined: Mar 05, 2008
    Posts: 3018
        
      10
    I'd have it implement Iterable<Row> so it works in enhanced for loops. But same idea.

    I'll add Stack to the list of legacy collections, even if it took much longer for it to be really superseded (by Deque).

    If we can include language features, I'd push for ditching checked exceptions as well. But I guess for that, I have basically every other language out there to choose from. Does any other language have checked exceptions?

    Anyway, I know that dislike of checked exceptions is far from universal, even if it is increasingly common, so it's probably too controversial for something like this. If they ever do such a ditch-the-old-stuff release, they should probably stick to non-controversial cruft that everyone can agree on. At least for the first such release.
    Paul Clapham
    Bartender

    Joined: Oct 14, 2005
    Posts: 18712
        
        8

    Here's my reason why backwards compatibility is important:

    I'm using all of these open-source projects. Probably dozens of them. So I can't move my code to Java PLUS™ until I have access to Java PLUS compatible versions of all of those projects. This of course would take time -- that itself isn't much of a problem, because I'm not really an early adopter, at least not at work, but it's possible that some of the open-source projects I'm using might not have anybody who wants to produce a Java PLUS version.

    In which case I would be stuck with no migration path. I suspect you would find a lot of people in that boat, not only for this reason but other reasons (like they don't have the source code for their application, for example). So all of a sudden code which you sort of thought might be legacy code is now LEGACY™ code.
    Mike Simmons
    Ranch Hand

    Joined: Mar 05, 2008
    Posts: 3018
        
      10
    Yeah, migration of open-source projects would be a major issue. Not impossible, but it could take a while. And this is why the release would have to avoid any controversial changes - migration would need to be seen as a near universal imperative. I'd like to think any open-source project that didn't do it would be seen as a dead project - and it should be easy enough to do that any halfway decent programmer could make the changes to an existing project and put out a new fork if necessary, absent official support from the original project. But maybe that's naive.
    Mike Simmons
    Ranch Hand

    Joined: Mar 05, 2008
    Posts: 3018
        
      10
    Oh, and if they don't have the source to something, it's definitely already legacy code.
    Matthew Brown
    Bartender

    Joined: Apr 06, 2010
    Posts: 4425
        
        8

    Jesper de Jong wrote:
  • java.util.Date and java.util.Calendar; these should be replaced by something like Joda Time (Project ThreeTen)


  • I think you'd have to deprecate these for a long time before you could safely remove them, regardless of how much better Joda Time is.
    Martin Vajsar
    Sheriff

    Joined: Aug 22, 2010
    Posts: 3610
        
      60

    While I'd eagerly embrace nearly all of the presented suggestions, I'm not sure it would be wise for Java the language from a wider perspective.

    Once upon a time there was a transition from VB6 To VB.NET. Our company never made it. We remained at VB6, since the transition to .NET (rewriting all that native API code) would be too much work for too little gain. We have still some apps in VB6 (and supporting them is increasingly painful, especially since the XP era ended), but we ditched the .NET for Java. Similarly here, lots of people could stay on the old version as long as possible, and then look for alternatives, since the switching to the new Java and another language X could start looking as comparable endeavors.

    I'm not sure how VB.NET is doing these days. I believe it was superseded by C# (and if we stayed on the .NET platform, I'd probably use C# too). Look at VB6 and VB.NET on TIOBE.

    I believe such a move could spell the end of Java. I don't think we - the developers - would be worse off, since it would mean that a better alternative would have eventually emerged. But still, I tend to like Java a lot.
    Mike Simmons
    Ranch Hand

    Joined: Mar 05, 2008
    Posts: 3018
        
      10
    Good point. I'm thinking it wouldn't be the end of the JVM, but maybe the decline of the Java language. Still, as long as the JVM ecosphere allows interoperability, that can work.
    Paul Clapham
    Bartender

    Joined: Oct 14, 2005
    Posts: 18712
        
        8

    Mike Simmons wrote:it should be easy enough to do that any halfway decent programmer could make the changes to an existing project and put out a new fork if necessary, absent official support from the original project. But maybe that's naive.


    It quite likely is naive. Let's take an example: me. I'm a halfway decent programmer -- actually I'd have to say I'm a pretty good programmer. But if you assigned me to take, say, Apache File Upload, and migrate it to the brave new world without Enumeration and Calendar and so on, I would consider that to be a pretty daunting task.
    Mike Simmons
    Ranch Hand

    Joined: Mar 05, 2008
    Posts: 3018
        
      10
    Well, having to replace Calendar would be daunting, I agree. I don't think Calendar should be removed for a long time, actually, just deprecated. Too much logic around how it's used, that a porter would need to understand. But Enumeration? No problem. Same for most of the other things listed - they have very straightforward drop-in replacements.

    Hm, I wonder if legacy libraries could be handled with a tool to do bytecode transformation, either at runtime or before. That's kind of tempting actually, for any components that no one has yet upgraded properly.
    Paul Clapham
    Bartender

    Joined: Oct 14, 2005
    Posts: 18712
        
        8

    I'm pretty sure that one of the first things to appear in this scenario of non-backwards-compatibility would be a Migration Assistant. Whether it would come from Oracle or from some third party, I couldn't really guess.
    Ivan Jozsef Balazs
    Rancher

    Joined: May 22, 2012
    Posts: 867
        
        5
    Mike Simmons wrote:
    Hm, I wonder if legacy libraries could be handled with a tool to do bytecode transformation, either at runtime or before.



    In the simple case of drop-in replacements yes, otherwise I am not so sure.
    Pat Farrell
    Rancher

    Joined: Aug 11, 2007
    Posts: 4659
        
        5

    The key question is do you want to remove old cruddy features from the compiler? or from the compiler and JVM?

    I'm 100% in favor of removing old crud from the language, and thus from the compiler.

    I expect that to support old libraries that contain cruddy features that the JVM will have to keep supporting them. But I don't like it. I want the old bad ideas to be banned. Type erasure is #1 on my hate list. This lack of support for modern language features, or the insanely complex way that some features are implemented (I'm talking about you, generics, with the 200+ page FAQ) rules out a lot of libraries from my development. The Apache Commons Collections was banned because of its non-existent support for generics.

    Sometimes, having to give up an old, cruddy library is good. I switched from commons-collections to Google Guava and got a bunch of neat new APIs for free.

    IMHO, if Java 8 doesn't remove the crud from olden-days, Java++ will. Evolve or die.
    Ivan Jozsef Balazs
    Rancher

    Joined: May 22, 2012
    Posts: 867
        
        5
    Pat Farrell wrote:
    I'm 100% in favor of removing old crud from the language, and thus from the compiler.



    Compilers are less the problem because
  • there can be (and, hélas, actually there are) several compilers producing classes.
  • there can be (and, hélas, actually there are) different compiler options (also relating to versions) to influence compilation.
  • There can even be (and, hélas, actually there are) several languages based on the the JVM and the class file format.

  • Jesper de Jong
    Java Cowboy
    Saloon Keeper

    Joined: Aug 16, 2005
    Posts: 14278
        
      21

    Yay, it seems that at least project ThreeTen is going to be included in Java 8: New Date and Time API Looks Set for Java 8.
    chris webster
    Bartender

    Joined: Mar 01, 2009
    Posts: 1786
        
      16

    My Java experience is now so obsolete that a lot of that "old crud" sounds like cutting edge new stuff to me. Anyway, I'm kind of hoping that by the time Java 8 comes around, the JVM/Java distinction will be so well established that there will be no real need for most of us to code in Java for the JVM when we can use Scala (or Groovy or Clojure or...) instead. All that fossil crud may still be there, but at least we wouldn't have to deal with it directly.

    As for the transition from "legacy" Java to crud-free "future" Java, the Python world is currently in the middle of just such a transition, as Python 3 is no longer fully backwardly compatible with earlier versions of Python, so it's kind of a pain working out which tools and open-source packages etc you can use with which version of Python. There is a conversion tool, but I don't know how reliable it is. Anyway, given the huge volume of Java code currently in use, and the impenetrable complexity/over-engineering (delete according to personal prejudice) of many massive J(2)EE projects, this task would be even worse for Java.

    So I reckon it's unlikely ever to happen.


    No more Blub for me, thank you, Vicar.
    Pat Farrell
    Rancher

    Joined: Aug 11, 2007
    Posts: 4659
        
        5

    chris webster wrote:As for the transition from "legacy" Java to crud-free "future" Java, the Python world is currently in the middle of just such a transition, as Python 3 is no longer fully backwardly compatible with earlier versions of Python, so it's kind of a pain working out which tools and open-source packages etc you can use with which version of Python. There is a conversion tool, but I don't know how reliable it is.


    This has happened many times in the past. Fortran had major conversion problems back in the late 70s.

    Its only a problem with popular languages. With niche languages, you just change and it has little impact.

    I fear that I share @chris' view that the huge legacy code, especially opaque stuff like J2EE, will make any transition painful. Which is why I think that "Java" may die and be replaced by some other language with a new name. I had high hopes for Scala, but it requires a bigger brain change than I think most programmers and most bosses can handle.
    chris webster
    Bartender

    Joined: Mar 01, 2009
    Posts: 1786
        
      16

    Pat Farrell wrote:I had high hopes for Scala, but it requires a bigger brain change than I think most programmers and most bosses can handle.

    I hope not - I only just started the Coursera Scala course...
    Jesper de Jong
    Java Cowboy
    Saloon Keeper

    Joined: Aug 16, 2005
    Posts: 14278
        
      21

    Pat Farrell wrote:I had high hopes for Scala, but it requires a bigger brain change than I think most programmers and most bosses can handle.

    Scala is a very nice, very flexible and powerful language.

    The problem is perhaps that it is too flexible - you can use it in wildly different styles. You can for example use it with a Java-like style, or with a hardcore functional programming style which will look very alien to most Java programmers.

    You could ask what then the problem would be with that - just choose your own style and go. But the thing is that you'll need to understand and use code written by other people. It's not pleasant if you need to use libraries which are written in, and assume you use them with a particular style that you're not familiar with.

    As a reaction to this perceived complexity and also out of the wish to have something that fixes the (legacy) problems with Java, there is a number of new and simple programming languages that run on the JVM: Kotlin, Ceylon, Fantom.
    Jelle Klap
    Bartender

    Joined: Mar 10, 2008
    Posts: 1794
        
        7

    Nah, I think breaking compatibility anywhere in the near future would be a big mistake.

    Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
    Winston Gutkowski
    Bartender

    Joined: Mar 17, 2011
    Posts: 8043
        
      22

    Jelle Klap wrote:Nah, I think breaking compatibility anywhere in the near future would be a big mistake.

    I have to admit, I tend to agree. In general, Java has kept to a pretty simple paradigm: the basics don't change. I do think, however, that maybe some new annotations could be added to enhance the business of deprecation.

    For example: an @Legacy annotation for classes like Enumeration (and StringBuffer ) that takes a classname (or set of them) to indicate the class(es) that have superceded the legacy one.

    It would also be nice to have grades of deprecation (or maybe simply a set of annotations that indicate the severity of deprecation) and tie them into javac so that a specific deprecation level can be considered an error, rather than just a warning.

    Winston
    Jesper de Jong
    Java Cowboy
    Saloon Keeper

    Joined: Aug 16, 2005
    Posts: 14278
        
      21

    Winston Gutkowski wrote:For example: an @Legacy annotation for classes like Enumeration (and StringBuffer ) that takes a classname (or set of them) to indicate the class(es) that have superceded the legacy one.

    There is already a @Deprecated annotation. There are things that Oracle doesn't make deprecated, such as StringBuffer and the legacy collection classes, even though there's no good reason to use them anymore. I wonder why they don't just make all that old stuff deprecated.
    Winston Gutkowski
    Bartender

    Joined: Mar 17, 2011
    Posts: 8043
        
      22

    Jesper de Jong wrote:There is already a @Deprecated annotation...

    Yes, I'm aware of that, but it seems to me that it's a bit of a catch-all. To me, "@Legacy" would apply only to a class and simply indicate that it has been superceded by another one (or more). It would also allow Oracle to indicate that a class is a legacy class without the otherwise possible dire implications of @Deprecated.

    Winston
    Campbell Ritchie
    Sheriff

    Joined: Oct 13, 2005
    Posts: 39478
        
      28
    Maybe a @Legacy annotation would allow you to prohibit its use in new code and permit its use in old code. That would maintain backward compatibility.

    I remember they were going to prohibit raw types in Java6. And I agree with Jesper that erasure has made generics a right mess. If only they’d had enough time or money or whatever to implement generics in Java1.
    Winston Gutkowski
    Bartender

    Joined: Mar 17, 2011
    Posts: 8043
        
      22

    Campbell Ritchie wrote:I remember they were going to prohibit raw types in Java6. And I agree with Jesper that erasure has made generics a right mess. If only they’d had enough time or money or whatever to implement generics in Java1.

    I certainly agree with the sentiment, but the fact is they didn't; and Bracha's paper on generics contains a fairly cogent explanation of why type erasure was chosen (basically the Hippocratic oath - Do no harm - although we know how that can get misinterpreted ).

    Dunno about you, but I've always considered Java generics as an "80% solution" (and probably better); and I've generally also found that if I run into difficulties, it's me who's to blame, not generics.

    Winston
    Jelle Klap
    Bartender

    Joined: Mar 10, 2008
    Posts: 1794
        
        7

    Currently the javac compiler generates warnings for code that uses an API that's annotated with @Deprecated, unless @SuppressWarnings("deprecation") is used.
    Maybe such an @Legacy annotation could generate compiler errors by default, and javac could introduce a new flag to mark those occurrences as warnings instead.
    Martin Vajsar
    Sheriff

    Joined: Aug 22, 2010
    Posts: 3610
        
      60

    Sorry to bother you all, but what should be the difference between @Legacy and @Deprecated? Yes, the list of recommended classes would be nice, as well as the "deprecation level", but we don't need a new class of annotation just for that. I seem to miss the point. When would @Deprecated be used and when @Legacy?

    (I'm also ignorant about the dire consequences of @Deprecated Winston has mentioned. Quick search in the docs didn't hint anything especially "dire" to me, but perhaps I'm just not sensitive enough )
    Rob Spoor
    Sheriff

    Joined: Oct 27, 2005
    Posts: 19725
        
      20

    Winston Gutkowski wrote:For example: an @Legacy annotation for classes like Enumeration (and StringBuffer ) that takes a classname (or set of them) to indicate the class(es) that have superceded the legacy one.

    You mean class literal, right?

    I don't think it would work to make the compiler throw errors when you use the legacy classes and interfaces, since they are used in too much existing code; Vector in JTable for instance, and Enumeration all over the place. You couldn't use large portions of the API without turning off these errors, unless Oracle would modify the API to add replacement methods / constructors for all that uses the legacy classes / interfaces. However, if a legacy interface is used by another interface all existing implementations of the second interface would break because they would miss the extra methods.


    SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
    How To Ask Questions How To Answer Questions
    Jelle Klap
    Bartender

    Joined: Mar 10, 2008
    Posts: 1794
        
        7

    Rob Spoor wrote:
    Winston Gutkowski wrote:For example: an @Legacy annotation for classes like Enumeration (and StringBuffer ) that takes a classname (or set of them) to indicate the class(es) that have superceded the legacy one.

    You mean class literal, right?

    I don't think it would work to make the compiler throw errors when you use the legacy classes and interfaces, since they are used in too much existing code; Vector in JTable for instance, and Enumeration all over the place. You couldn't use large portions of the API without turning off these errors, unless Oracle would modify the API to add replacement methods / constructors for all that uses the legacy classes / interfaces. However, if a legacy interface is used by another interface all existing implementations of the second interface would break because they would miss the extra methods.


    Ooooh, I didn't really think that thru did I?
    Winston Gutkowski
    Bartender

    Joined: Mar 17, 2011
    Posts: 8043
        
      22

    Martin Vajsar wrote:Sorry to bother you all, but what should be the difference between @Legacy and @Deprecated? Yes, the list of recommended classes would be nice, as well as the "deprecation level", but we don't need a new class of annotation just for that. I seem to miss the point. When would @Deprecated be used and when @Legacy?

    (I'm also ignorant about the dire consequences of @Deprecated Winston has mentioned. Quick search in the docs didn't hint anything especially "dire" to me, but perhaps I'm just not sensitive enough )

    Well first, to me @Legacy would only apply to classes that have been "superceded", and could possibly be used to help programmers refactor their code.

    The problem with @Deprecated (to me) is that it's too broad. Take, for example, java.util.Date, which has a number of deprecated methods:
    1. Most of the 'getters' have simply been deprecated because there's a more consistent alternative provided by Calendar (and, quite possibly, they've been refactored to use those methods anyway).
    2. getTimeZoneOffset() is positively dangerous, because it's DST sensitive and returns a value that is NOT consistent with offsets used elsewhere.
    3. Arguably, UTC(), toGMTString() and parse() didn't need to be deprecated at all, since their use is fully documented and doesn't involve Locales, so they can't really be misinterpreted.

    Then you have things like Thread's destroy(), suspend() and stop() methods, which really should not be used - indeed the docs say that the latter is "inherently unsafe" and the first was never implemented. To me, that's a long way from simply saying "there's a better alternative".

    And that's my basic problem with @Deprecated: it's too broad, both in scope and meaning. To me, more descriptive names like @Dangerous or @Redundant or @Superceded, especially with methods, might help to describe the reason for deprecation, and also its severity.

    @Rob - Just to be clear: I wasn't thinking of making javac throw errors, I was simply suggesting that it might be possible to have it optionally throw errors based on some sort of 'deprecation severity'. And you're right; a Class literal would be much better than a name.

    Winston
    Paul Clapham
    Bartender

    Joined: Oct 14, 2005
    Posts: 18712
        
        8

    Here's something I would like to see cleaned up: numbers.

    Right now Java exposes its reliance on a certain underlying hardware platform: 32-bit integers, IEEE-754 floating point. And as usual when you have a leaky abstraction, you have gotchas. Like adding 1 to an integer value repeatedly eventually rolls over from a big positive number to a big negative number without warning.

    And then there's those wrapper classes: Integer for int and so on. Of course they had to throw in some badly-hidden optimizations when they implemented them, so now we have another class of gotchas for all the students to fret over. There's == which works inconsistently, and there's the possibility of having a null Integer variable.

    That's all old stuff and it's a mess. I would like to see it all tossed out and replaced by a more sensible system.
    Mike Simmons
    Ranch Hand

    Joined: Mar 05, 2008
    Posts: 3018
        
      10
    Yeah, I agree numbers should be cleaned up. But I suspect that would be more involved than most of the other changes here, and a lot of it is endemic to the JVM, not just Java. That could be a tough nut to crack.
    Winston Gutkowski
    Bartender

    Joined: Mar 17, 2011
    Posts: 8043
        
      22

    Paul Clapham wrote:Here's something I would like to see cleaned up: numbers...

    Oh yuss. Gold star from me. Quite apart from all the stuff you mentioned, doesn't it seem surprising to you that you have a Number interface (or indeed wrapper objects) that you can't do arithmetic on?

    Winston
    Tony Docherty
    Bartender

    Joined: Aug 07, 2007
    Posts: 2332
        
      50
    And whilst they are sorting out numbers in Java can they please add a Money class and a MoneyFormat class.
    Campbell Ritchie
    Sheriff

    Joined: Oct 13, 2005
    Posts: 39478
        
      28
    You are probably too young to understand public class LSD extends Money.
    Jayesh A Lalwani
    Bartender

    Joined: Jan 17, 2008
    Posts: 2414
        
      28

    I think the 2 ideas I like are
    a) Throw old stuff out from the compiler, but keep it in the JVM. This would prevent any new code from using old features. Legacy code that is built with Java 6 compiler should still run in Java 7+ JVM
    b) Allow interoperatibility using an @Legacy annotation.:- So, if I have this code that is built using Java 7 that relies on a jar that was built using Java 6, it should all compile and build well. However, any functions that are built using Java 7 need deprecated API, that function should be marked with a @Legacy annotation. The function marked with @Legacy can use expired Java 6 classes, but cannot expose them. For example

    if I have a class that is built usign Java 6



    My new Java 7 class can do this


    but can't do this


    My new Java 7 class can neither do this


    nor this




    Winston Gutkowski
    Bartender

    Joined: Mar 17, 2011
    Posts: 8043
        
      22

    Jayesh A Lalwani wrote:b) Allow interoperatibility using an @Legacy annotation...

    Hmmm. Rather like that. I think it'd need fleshing out a bit, but I certainly like the idea.

    Winston
    Martin Vajsar
    Sheriff

    Joined: Aug 22, 2010
    Posts: 3610
        
      60

    This is a wonderful thread of ingenious proposals. Now we only need to nail down one last thing: what name should we give to this language?
    Matthew Brown
    Bartender

    Joined: Apr 06, 2010
    Posts: 4425
        
        8

    Jayesh A Lalwani wrote:
    My new Java 7 class can do this
    ...snip...

    but can't do this
    ...snip...


    I like the idea in principle. A couple of potential gotchas - would it be able to do this?
    or (if the compiler tries to be clever enough to detect that) this?

    In other words, would it be a problem to return legacy types as long as they were never referred to as that type?
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Should old stuff be removed from a future Java version?