When is it OK for Java to Break Backwards Compatability?

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

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.

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.

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.

@jacek

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?

@Howard

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') ?

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

@Arthur,

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.

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.

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.