Should Java break backwards compatibility in future versions for the benefit of a cleaner language?

Question

• Are primitives worth keeping?
• Should all the deprecated stuff be deleted?
• Do we need 2 GUI frameworks?
• ...

Answer 1

Since, a major portion of market share still uses older jdk/jre I don't think it will be pragmatic to break backward compatibility.

Answer 2

As I have already mentioned, even in its How and When To Deprecate APIs, nothing is being said about a policy regarding actually removing the deprecated APIs...

The number of applications based on older JVM (1.4 for instance) is still important, in part due to application servers which take a long time to validate themselves with new versions of JVM...

The sheer number of applications which are actually running in production means this “backward compatibility” policy may not be broken anytime soon.

Answer 3

As Pat said, the adoption of newest JDK version is quite slow, and a lot of applications are currently running using old (sometimes really old) versions of Java.

Thus, I don't think there is a real benefit of not assuring the backwards compatibility.

For your suggestions, I don't really see the interest of removing the primitives. Of course, there is autoboxing since Java 5. However primitives still have their interests...

Answer 4

Breaking compatibility would make sense if the JVM keeps the same. In that case the "new" Java would become a new, different language running on the JVM, such as those listed there. Fortunately, the way the JVM is designed guarantees interoperability between languages and versions, so I think the impact would be limited.

Answer 5

You can do this with hobby (Ruby), low implementation (Python) languages, but you can't imagine how many apps are written in Java around the world. Just check freshmeat or sourceforge. And that's only a portion. So no, it's not a good idea. Actually, it would be a pretty stupid idea.

There are not two GUI frameworks. Swing depends and uses AWT as it's basis.

Answer 6

I think a fork would be more appropriate to give the language a proper overhaul. The way Java's generics work is starting to piss me off, frankly.

Answer 7

The reason I left PHP is that they alter the API/available functions between major version upgrades. The real problem is that PHP cannot run in a compatebility mode, for older scripts. I don't want to be FORCED to upgrade my code.

Java is in the same spot. Just make sure you can use the old 1.4 stuff, on the new versions. It's ok to require new programs to use a new xyntax, but make the old stuff run!

Answer 8

Regarding primitives, they will always be there, like it or not, because they are the basic building blocks of objects. Sure, you could use the wrapper classes instead, but that just overworks the compiler, which ultimately translates back to primitives in most cases.

Backward compatibility is very important, and as folks already mentioned here, there are a lot of users still running 1.3 and 1.4 code. Having said this, I think if anyone is still running java 1.0 or 1.1 code in some legacy system, they're not likely to migrate to Java 7 any time soon, and even if they do, they'll most likely need to rewrite their code anyway. I think the deprecated API of versions >1.2 can safely be removed.

Another aspect of backward compatibility is addition of keywords, which is always discouraged. in Java 5, the major language changes were managed with the addition of a single new keyword, 'enum', and even that caused an outrage, since every piece of code with a variable named 'enum' was now non-compliant. As far as I know, the changes in Java 7 are planned without new keywords (phew!).

Yuval =8-)

Answer 9

It will be good, depending on Sun not shoving new JDK upgrades to all its clients. Those who use old APIs will not upgrade and will use an old-version JDK for a while.

Or, perhaps, by implementing backwards-compatibility mode.

Answer 10

Breaking backwards compatibility is a major step in any language, it would be a perfect excuse for lots of developers/companies to look around for alternative languages.

Although I'm usually a Java programmer, I occasionally have to maintain a VB6 project - it was the change to VB.NET that lost us.

Answer 11

I would really enjoy if certain deprecated features were removed - for example, if the Date object was truly made immutable I would be very happy. As it is, if you're writing an immutable class you can't assume Dates are immutable and have to defensively copy them, for instance, and you can't reliably use them as keys in Hashmaps (since in both cases, other code can mutate the Date regardless of whether the methods are annotated as deprecated or not).

When it comes to adding new language features, I don't fully understand the backwards compatibility mantra. To my mind, it isn't that big a deal if code written for a previous version needs some tweaks to run in a later version. In fact there is precedent for this anyway; between 1.5 and 1.6, extra methods were added to the ResultSet interface, and so code that would compile and run under Java 1.5 wouldn't even compile under 1.6.

Considering legacy apps, is it reasonable for someone to expect an application that hasn't been updated in 5 years to run perfectly on the latest version of the JVM? If organisations are still using Java 1.4 and applications that were written for it, do they really care what goes into Java 7? Breaking backwards compatibility does not mean that all previous versions of JVMs will become broken as well. If the app is targeted at an earlier version, one can just run it on that version of the JVM with no worries.

Most importantly, as time goes by and people use Java, mistakes and feature gaps become evident, and correcting/implementing those would be a major boon. Being straightjacketed when trying to improve the language because of what came before if unfortunate, and in my view not a fundamental requirement.

Of course, there would need to be some thought towards the upgrade path. To suddenly change ints to Integers, for example, would require masses of tedious code changes for everyone (as well as having to add extra null checks, etc.). However, adding a new feature that happens to break backwards compatibility (e.g. closures), or removing methods that have been deprecated for years, will have little effect on existing code. (If you've been using deprecated methods then tough, you should have removed them before but now you're forced to!)

Answer 12

I would say breaking backwards compatibility is a stupid thing to do for java. If so, you may call it Java++, it is not Java anymore. On the other hand, for future versions of java, it should learn from dynamic language for features such as syntax simplicity. Since hardware power is increasing so fast-paced, the abstract level should be higher for a compiling language. Comparing some features of current java versions with dynamic languages, it is too clumsy and verbose, thus less productive for development. It seems C# is becoming a dynamic language?

Answer 13

For compatibility reasons they can't do that with the standard Java releases. There is so much Java software in production out there right now that you simply can't break it with a new release that removes all the cruft.

However I do think that Sun could make a "Java X" release that removed everything that was crufty, and added all the good and useful APIs that are out there but not currently included (including replacing Java APIs that have better alternatives available, e.g., log4j, and let's not start on Date and Calendar). This release would not be designed to replace Java, but could exist as a target for new software projects. I guess they could also fix up the language to include features that are missing that make Java look a bit crufty in comparison to the latest versions of C#, etc. If they made a code porting tool as well that could fix up or at least add "FIXME" to all problem areas in a codebase ...

Gotta admit, Microsoft does a good job of moving people on to newer versions of .NET when they come out. Sun has totally failed here, given the number of applications still running on 1.4, and the lethargic Java version policies of many companies (who seem happy to let their .NET people use the latest and greatest somehow). Given that it is simple to have multiple Java installs on a machine, I think that more should be done to encourage companies and software houses to upgrade sooner.

Answer 14

There are several types of backwards compatibility:

1. Can old source code compile with the new compiler?

   This can be handled with tools that convert old constructs to new ones, or with something like a "source 1.6;" directive at the top of the file.

2. Can old class files run in a new JVM?

   In my world this is a complete show-stopper. We use so many third-party libraries that forcing a simultaneous upgrade of all of them would be too costly.

   This is also the driver for not removing deprecated classes and methods, but to a lesser extent.

3. Can old class files call code compiled with the new compiler?

   This is an important part of #2, because of callbacks.

4. Can newly compiled code call code from old class files?

   Another important part of #2.

5. Does the code look substantially similar to developers?

   This is important for training, and for working large codebases that have not completely converted. A subtler aspect is how much of the new feature can be used in a mixed codebase. If you break this too far, you've got something like Scala instead of Java++.

Generics were added in such a was as to preserve all of these types of compatibility. I think that any incompatible change to Java has to preserve at least 2, 3 and 4 to have any chance of acceptance as Java. Tools to handle #1 are also a minimum requirement.

Answer 15

With many great alternative languages on the JVM, I really don't see any reason why. I'd rather have a stable Java, and move on for the cool new stuff (and still remain compatible with Java).

Answer 16

I think some API for example date time should be rewritten. If the current version receive it EOL then the old API should be removed. Our statistic show that 99,3 % of our customers use Java 6 or newer. There is no need for compatibility very old API. But there must be a clear time frame if a API will be removed.