I've been a zone leader with DZone since 2008, and I'm crazy about community. Every day I get to work with the best that JavaScript, HTML5, Android and iOS has to offer, creating apps that truly make at difference, as principal front-end architect at Avego. James is a DZone Zone Leader and has posted 639 posts at DZone. You can read more from them at their website. View Full User Profile

When is it OK for Java to Break Backwards Compatability?

  • submit to reddit

At Devoxx last week, attendees were asked if Java 8 or 9 should be backwards incompatible, on a community whiteboard. The results from that survey can be seen below: most developers want to see compatability broken to get the new stuff in. In this poll, I'd like to see how important backward compatability is for you when it comes to versions following Java 7?


I would be really interested to hear the reasoning of anyone who things that it's ok to be backwards incompatible.

Image provided by Stephen Janssen.


Howard Lovatt replied on Mon, 2010/11/22 - 2:24am

My favourite option is to add to the start of a file:

source 7;

before package, this way it doesn't break old code (old code doesn't have a source 7 line and is therefore 6). The action of the source 7 line is like the source flag and it overrides the flag.

I have suggested this a number of times but Oracle don't seem keen :(

Attila Király replied on Mon, 2010/11/22 - 2:51am

Reified generics would be nice even at the cost of breaking backward compatibility.

Dhananjay Nene replied on Mon, 2010/11/22 - 3:29am in response to: Howard Lovatt

How would that work if say type erasures were removed in the next version of java? :)

Andrew McVeigh replied on Mon, 2010/11/22 - 5:25am

we are basically discussing whether the ongoing evolution of java requires a breaking change.

IMHO all technology must be reinvented/evolve to stay current - everything has a shelf life and if you don't reinvent things move on and make the older technology seem old (the perception factor) and clunky (the modern usage factor).

so, my ideal scenario would be:

1. start 2 streams: old java and new java

  -- publicly state that both will be fully supported going fwd

2. new java is then free to

  (a) make breaking VM changes (type reification for generics, tail call optimisation etc)

  (b) remove redundant or obsolete libraries (corba, awt?, possibly even swing ;-)

  (c)  introduce breaking language changes

3. look for an interoperability story - perhaps a VM that supports both.


Of course, the above can't happen. It would require far too many engineering resources, and be far too big a risk.  So the answer is: a breaking change is not possible - there are too many constraints.

Philippe Lhoste replied on Mon, 2010/11/22 - 7:54am in response to: Andrew McVeigh

AWT obsolete? I don't see currently a replacement for Color, Font, Rectangle2D or BufferedImage...

Gil Collins replied on Mon, 2010/11/22 - 8:12am

I can see both sides of the coin on this.

Breaking compatibility would make many projects have to invest massive amounts of man hours in order to get their code back up to date, this would definitly cause issues and may even have some defectors to other languages since they would be making such an exorborant amount of changes.

 On the other hand breaking compatibility could allow more streamlined and advanced capabilities for those companies willing to devote the time and money to move onto the latest version.

 Maybe the backwards compatibility stay's by way of creating an API that duplicates what was there but offers new and advanced ways of execution.

Jacek Furmankiewicz replied on Mon, 2010/11/22 - 11:09am

I am OK with breaking backwards compatibility in some key areas, if it's for the better in the long run. We practice TDD on our team and have a thorough suite of *integration* unit tests (thank you Maven and Jetty), so any breakage would show up pretty fast for us.

Andrew McVeigh replied on Mon, 2010/11/22 - 11:24am in response to: Philippe Lhoste

AWT obsolete? I don't see currently a replacement for Color, Font, Rectangle2D or BufferedImage...

I guess i meant the AWT peer widget model.  What you've just listed, i'd call part of Java2D.  Even that's up for grabs though, apparently, with the new JavaFX libraries and updated compositing model.

Jim Bethancourt replied on Mon, 2010/11/22 - 1:14pm

Perhaps javac could produce Java 7+ bytecode (or whatever version backward compatiblity is broken) that starts with something other than CAFEBABE and the bytecode JVM could look for the same start sequence, but most other behavior would be the same. This way, perhaps the two runtimes could coexist and just have different compilers that are bundled into javac and use compiler flags to differentiate.



Artur Biesiadowski replied on Mon, 2010/11/22 - 1:23pm in response to: Jacek Furmankiewicz


How manyof your unit/integration tests would detect thing like memory model change which happened between java 1.4 and 1.5? It would completely kill some of my applications (which were written to take advantage of java 5 model) - but am I really supposed to unit-test the way volatile does a memory barrier?


How 'source 7' is going to help with things like removing AWT or reified generics (in places where you interact with code compiled without 'source 7') ?

Ronald Miura replied on Mon, 2010/11/22 - 3:04pm

  1. Should always be possible to use old jars in future VMs (very few people would throw all their libraries through the window just to use closures...)
  2. It's not necessary for future versions of .class files to run on old VMs (Java 6 binaries don't run on Java 5, and Java 5 don't run on Java 1.4)
  3. It's not necessary to keep source compatibility too (Java 5 was not compatible with Java 1.4, Java 1.4 was not fully compatible with Java 1.3)
  4. It's very desirable (and probably very easy) to be able to compile old .java files with future versions of javac, even if the future Java isn't source-compatible
  5. It's perfectly fine to create specialized 'editions' of Java, just like Android, GWT and Java ME
  6. It's mostly fine to deprecate and make optional some never-used standard APIs (aka CORBA and MIDI support). It's important to make them available as optional packages, though
  7. If language changes break too much (although how much is 'too much' is very debatable), it's better to make another language instead, just like Scala and Groovy
  8. We should just accept that AWT and Swing will never go away. Maybe in the (far) future they will become on-demand-installed packages (Java Kernel?), but they could never be ripped off the JRE without taking with them all the trust Java has built in all these years of stability

Josh Marotti replied on Mon, 2010/11/22 - 3:09pm in response to: Howard Lovatt

Elegant solution that seems to help both worlds.  I hope Oracle changes their mind on your idea!

My thoughts: Honestly, I just want generics to work as intended, which means breaking backward compatibility.  I want this more than closures, so, please, break compatibility to make a better product.  We don't mind...

Cloves Almeida replied on Mon, 2010/11/22 - 5:48pm

Maybe Java should follow Python's route from 2.x to 3.0 series. Fork, from Java 8 into "Java NG" and maintain parallel editions. "Classic" Java would be publicly mantained for a few more releases with appropriate deprecation warnings to soften migration. Deprecation warnings should be printed on runtime usage of deprecated classes and method so code relying on XML/String wiring could be more easily corrected.

Doing "Classic Java" emulation for compiled code to use existing libraries shouldn't be that hard or underperformant.

Oracle could even setup a special support contract (revenue!) for those "can't touch this" doomsday-critical applications that can't be ported.

What shouldn't happen is to allow Java to become the "next COBOL" and be completely ignore for greenfield projects.

Howard Lovatt replied on Tue, 2010/11/23 - 1:37am in response to: Artur Biesiadowski


For things like removing packages as opposed to just deprecating them, you need a module system. One is planned for J8. Therefore source doesn't need to deal with this.

With completely incompatible changes source would simply raise an error. However you could probably do reified generics, my personal number 1, by introducing some new syntax to mean erased or pre-generic code, for example:

source 7; // 8, 9, who knows for reification
List<Integer> reified = ...;
List<@Erased Integer> erased = ...;

There may be better solutions, this is something people will need to work on (it isn't going to be easy to reify generics). However the success of the NextGen project gives hope that it is possible.

  -- Howard.

Anthony Goubard replied on Tue, 2010/11/23 - 3:16pm in response to: Ronald Miura

9. With project jigsaw (modularity in Java), it will matter less as you won't need the full Java API to run an application.

James Jamesson replied on Wed, 2010/11/24 - 2:35am

Along with other things, Java has become very popular because of its backward compatibility. If that is broken at some point, the degeneration will start. For example, java.util.Date may be depreciated but there are huge number of libraries out there use it. These libraries are still in use by businesses as well. Therefore although breaking backward compatibilit may sound pretty with cream to the many Java developers out there, in business perspective that is undoable. Oracle will never break its backward compatibility which is one of the reasons many businesses still use Java for development knowing that their library or software wont be absolete in the future. If they drop the balls on backward compatibility, Java will be unpopular in many BUSINESS circles in record time. Guess who will gain from that? there is a huge company which is notorious about backward compatibility has been waiting Java to loose some ground.

Claude Lalyre replied on Wed, 2010/11/24 - 10:19am

How old are C or C++ languages ? Is it really needed to break anything ? If you don't like Java, you are free to code with Ruby, Groovy, Scala or whatever JVM language you want. Instead of breaking Java, you should simply create a brand new JVM language as the one above... One more language on the market !

Shawn Hartsock replied on Mon, 2010/11/29 - 12:07pm

In my opinion, if we change Java so much it breaks backwards compatibility we should just call it something else. Call it JavaNext or Java++ or even Orava (Oracle-Java). Don't confuse things by keeping the same name. If you want to stay with a name that has history and recognition behind it use the name FORTRAN.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.