Will Sun ever make the step to "Java 3"?

Question

(Java 3 refers to theoretical post-Java-7 releases, remember: "Java SE was known as Java 2 Platform Standard Edition or J2SE from version 1.2 until version 1.5." That's why the name "Java 3" was chosen to refer to some future Java versions.)

"Evolve and keep compatibility to old, deprecated APIs or redesign from scratch and loose all compatibility?"

A question that most people would answer in favor to compatibility. But innovation must occur. And it's limited when you don't redesign.

Java has a mature and serious ecosystem. But can it keep up with .NET?

Of course, Java evolves:

1. Look, Java 5 introduced enums. So what are one million "final static int" fields are doing in the JDK? They remain for compatibility reasons.

2. Look, Java 5 introduced generics, but type erasure limits their functionality in favor of being backwards compatible.

3. URL's equals(...) is broken by design. Its return value depends on the host's network connectivity. It can't be fixed without breaking compatibility.

4. Modern paradigms suggest throwing exceptions, but all the ancient JDK classes (such as File) return false when 'something' goes wrong.

5. The Thread class has 6 methods that are deprecated since Java 1.2. They have been deprecated for ten years now and still won't be removed. (see the list of deprecated classes/methods/fields in the JDK)

Java 7 is underway. Lot of new sub-APIs (new NIO, ...) and new language features (project coin) are proposed. But what is the benefit of tons of new language features and sub-APIs, when 95% of the JDK just don't change at all?

So, who of you think that there is a probability that Sun could some day redesign Java to allow real innovation?

And if Sun will not, does Java as we know it have a future?

Answer 1

Chances for redesign from scratch: 0.

Too many projects would be affected if such a thing happened. As for Java's future, I don't think this is a problem.

Answer 2

Sun won't but IBM might (when they own Sun/Java).

Actually that's not true: they won't either.

Java 2 was really a silly naming convention introduced in Java 1.2, which led to confusing observations like "Java 5 is the Java 2 platform version 1.5".

So there won't be a Java 3, just more versions of Java.

Answer 3

Perhaps something like Scala is what you are looking for. It runs on the JVM and has access to all of the Java feautures, but addresses much of the issues you mention.

Answer 4

So, who of you think that there is a probability that Sun could some day redesign Java to allow real innovation?

I think you're forgetting that "Java the language" isn't "Java the platform" or "Java the virtual machine". We're already seeing some great innovation from alternatives like Groovy, Scala, and Clojure. These fix much of what people dislike about Java (the language), and still let you access the accumulated libraries and toolsets that people have written.

Many of these tools have no peers in other spaces -- try finding something that's as nifty as Maven, for example. And what you can do with the libraries is always evolving too -- if you hate it, there's almost always better ways of doing things with Apache Commons and other contenders.

Finally, if Sun wants to be aggressive and modify their existing development path, there's no reason why the Java libraries can't simply be forked. New, interface-breaking development can proceed while the old libraries retain their stability and previous implementation; nothing can break if you stick with the status quo. Critical fixes can be backported as appropriate, but if you want the new stuff you might have to do some rewriting.

Answer 5

Java will never be redesigned from scratch, simply because there is too much existing Java code out there which would become unusable, causing a redesigned Java to be equally unusable. Innovation and redesign is, as other posters have mentioned, already being made at the JVM-level. (The same argument can be made for C++.)

Answer 6

Breaking API changes might be more possible as is usually thought.

At a recent talk at Devoxx'08 Mark Reinhold (the Chief Engineer for Java SE) talks about the Java modularization plans and Java 7 in general.

At slide 32 of his talk he hints at the possiblity of introducing breaking API changes thanks to a modularized JDK/API. He goes on that this is definitely not in the near future, but it's a possibility.

This would be possible, because all modules (and all dependencies) would have associated version information. Legacy code without that version information could implicitely be dependent on the last JDK version without those breaking changes and thus run unchanged.

Note that this is mostly about library features. Language- or platform-level changes are not really possible with this (unless some future version defines even the language and/or platform as a module).

Answer 7

My experience in industry leads me to believe that if this happened, it would cut the java community in half. (I'm not, however, saying this is automatically a bad thing, just a probable outcome)

I've worked on a lot of different java projects, and almost never officially worked in java 1.5 or later.

Currently I'm working on Cable Boxes, they are stuck at 1.4 with a 1.1 api (no swing). Just before this I worked on a UI for an o-scope that ran AWT/1.1

Before this, various companies that saw no need to go through updating their code from 1.3 or 1.4. (The biggest problem being older purchased libraries that would fail under newer VMs)

On top of that is language complexity. The Java 1.4 language can be completely understood by many with average capabilities (in a way that they could never understand most other languages). Simply adding the syntax of generics into the mix dumped probably 1/3 out of that group.

To increase complexity more (which may happen with closures, or may not depending on the implementation) would probably mean that some companies would just strand themselves at their current version and never upgrade. Some are already refusing to deal with Generics.

Personally if I were interested in better features in Java, I'd just look at Groovy or Scala and forget about waiting for Java to evolve to 3.0.

In fact, (Please offer opinions if you disagree)--the only reason I can see for needing Java to evolve over going to another language is that Java is being mandated by your company and you want more. If this is the case, be sure you consider the fact that there is a good chance that a large (3.0) change in Java would leave you stranded in java-2 land anyway, but that now it would have even less development work on it.

Answer 8

Contrarilly to most posters, I think that Java is a great language, but the libraries are full of crap. However, these libraries are the main reason for Java's popularity, so I don't think Sun (or IBM) will take the risk to change them. Perhaps some deprecated methods and classes could be removed though.

Answer 9

"Java SE was known as Java 2 Platform Standard Edition or J2SE from version 1.2 until version 1.5."

Who are you quoting here? Sun? I remember reading something like this before.

The drop of J2SE, J2EE in favor of Java SE, Java EE obey more to marketing strategy than technical aspects.

Also, I remember something about the development/release strategy change in Java, while before they have a minor release following by several bugfixes the current approach is work directly on the next release and provide updates of the previous one.

The developer "view" remains the same that's why there is JDK 1.5, 1.6, 1.7 as before, because, well from behind is still the same.

So, there won't be a Java 3 as such, probably there will be Java SE 7, 8.

Talking about breaking backward compatibility I think that's not any close in Sun's mind.

One of the reasons for Java to exist, is to fix all the bad things there were wrong C++.

Many developers complaint about the new features C++ had that make the language awkward. The standard library was very very large. The security model was not the safest, and in general programming in C++ was a unpleasant experience.

So, Java started as a new programming language that would fix all these things ( actually it started at a language for the Green project ) by providing a cross platform binary, enhanced security model, cleaner ( back then ) standard library etc.

The release of Java and the demos of Applet technology ( which never materialized by the way ) create the boom of internet and Java's name was associated with internet very deeply. Even today 2009, there are people who associate web development with the Java programming language.

The change was so big that it created new approach to technology. Back then the most commonly used language used to develop Windows apps was Visual Basic. Nobody took seriously VM's ( now is quite common ) and scripting languages had place only for small administrative tasks.

So, this model ( keep backward compatibility, create cross platform etc ) is very very deep into Sun's culture, it put Sun Microsystems in the top of the technology wave. Working in Sun was once as cool as before was working in Microsoft or later was to work at Yahoo!,Amazon or now Working at Google.

Sun even change its NASDAQ name from SUNW to JAVA!

That's I think the reason why Sun haven't changed that much the way Java is.

Despite all this, they have opened the technology and there are several good programming languages for the JVM. They are still allowing new changes, but in a evolutionary approach rather than in a revolutionary approach.