Is Java due for a reboot?

Question

Java is now nearly 14 years old, and the age is starting to show. In my industry (banking), we joke that Java is the COBOL of the 21st century; except it's not much of a joke, it's the sad reality.

Java has a lot of "baggage" that is kept for backwards-compatibility -- exactly the kind of stuff that is critical for clients like banks. But I often think that it's high time for a reboot. Just read "Java Puzzlers" to find a list of pain-points in the language design. I'm not blaming the language designers -- a lot of lessons were learned in the past 14 years! However, I would really love some major changes that will happily break backwards compatibility while making the language much better.

Here is a (very partial) list of things I'd change in the language:

• Drop all deprecated items. It's high time Thread.stop and friends, for example, will die.
• Disallow overloading. It was a mistake. (I know this one is a bit controvertial, and yet...)
• Constructors must be private, only. Static methods should be used as factory methods to obtain instances. This allows for major and important optimizations. (Again, controvertial, but the academic community seems to agree. See also Item 1 in Effective Java.)
• Drop dead/mis-designed parts of the API. In particular, fix the Date class.
• Drop "finalize".
• Drop support for "raw" variants of generic classes. No more List; it has to be List<Something>.
• Properties. And no non-private fields while you're at it.
• Provide a default implementation of "equals" that iterates over fields and invokes their "equals"; allow some annotation ("@NonState") to mark fields that are not part of the equality test.
• "==" should invoke equals(); add a new operator, "is", for identity.
• Remove "clone" from Object; only objects that implement Cloneable should have this method.
• Allow a special annotation for test classes; test classes should be able to access private members of all classes in the same package.
• Make good use of Enums in the library -- curerntly, a lot of older classes use int constants instead.
• Drop "Thread.run"; Thread.start should accept a Runnable object (you'll be amazed at the number of bugs I've seen where Thread.run is called instead of Thread.start).

That's just off the top of my head... So, I'd like to hear:

• Do you agree that a reboot of Java (a new version breaking compatibility with old code) will be a good thing?
• What are your pet peeves, things you believe need fixing in the language? My own examples focused on compability-breaking items -- things you just can't do in current Java without breaking existing code. But other ideas are also welcome.

Clarification: I'm not looking for a new language (like Scala or C#). I'm looking for something that is clearly still Java -- but requires some porting effort for existing code. Note that for many of the changes I've suggested, code can be ported automatically or semi-automatically. I know banks won't adopt it any time soon (hey, I work there) but I also know that banks often start new projects, and would love to take advantage of existing programmers' knowledge while enjoying a better language.

To all those claiming that, for many of my suggestions, the team can just enforce its own rules (e.g., no overloading): true enough, but we're highly dependent on third-party code. Isn't everybody?

Answer 1

I agree that a breaking revision is a good idea. From your list, I particularly like properties -- maybe similar to C#'s implementation. The sheer amount of get/set boilerplate is staggering, and there's no reason for it.

Answer 2

Most of what you ask is for an API change instead of the language itself. You can always design your own base class library and start with that, if you are not happy with the current one.

Away from telling you to do that, but you can always look for alternatives before trying to fix the current issues, there is also .NET that have a lot of features of what you ask for.

Answer 3

I don't think languages ever get this sort of extreme makeover, especially not one that would break backwards compatibility in a million different ways like your suggestions would. Instead you get a new language.

Answer 4

I broke away from Java 12 years ago. 12! At the time, I didn't agree with the approaching change that was J2EE.

I like many concepts of the language, but it doesn't help to be backed by Sun (yuck) and needs to be majorly rebuilt from the ground up.

Something new, "java like".

And, in my (small) community, all of the Java developers are unfortunately referred to as "dinosaurs", in that they act like the COBOL developers used to act...absorbed in their own world, unaware that things have moved on, mostly without them.

Answer 5

I don't know if you've seen Scala, a newish language created by one of the original authors of Java, which runs on the JVM.

Languages very rarely get the sort of "reboot" you describe, you usually just get new languages. VB is about the only exception I can think of.

Answer 6

Breaking legacy code will only provide large enterprises a reason to consider other platforms. 1970s era C still compiles in today's compilers ... although some functions may be flagged as deprecated (which is a better solution, IMO). I would be furious if large parts of an enterprise application just wouldn't compile because my team upgraded to a newer version of Java.

Answer 7

Banks are usually not interested in bleeding edge technology. Bank want mature, stable technologies with a proven track record. There is very little use of popular languages which have only been around for a few years so inventing a new one would see it introduced into banking until it has been a round for a while and has much the same baggage.

Most of the Java puzzlers have been around in programming languages for a while and still exist in new languages. These are programming puzzlers written in Java.

I think most people would disagree with most of your points, even the ones I agree with. This is the problem with starting a new language.

Answer 8

I don't think Java should (nor it will) be rebooted. Every language has its issues, and now that Java is mature enough so that its issues are well known (and good developers can take them into account), the language should be changed?? No way.

Of course, a new language, founded on Java's lessons learned, could be started. Actually it already is here, its name is C#. Too bad that it's in practice a proprietary MS product.

Answer 9

Java is now nearly 14 years old, and the age is starting to show.

It's just a language. If you made all the changes you propose, I don't believe it would fly - it took 5 years for java to find its place, and a 'reboot' is going to cause problems with backwards computability.

This may not seem much of an issue, but it means billions of dollars worldwide in changeover costs for many companies.

Further, you'd then have the possibility of running the older version and the newer version on the same servers with interesting results or complex configurations.

Are these issues preventing you from doing something you need to do? Then don't worry about it.

The keepers of java know that if they don't keep it up to date the people will bail onto one of the newer languages over time, and they will change it to adapt.

But keep in mind that it's good for old languages to die and new languages to come of age. It's not always best to keep a language in active use and development as computers change, or reanimate it with some backwards compatible breaking but rejuvenating potion.

Answer 10

There are more people working to squeeze the h*ll out of java than most other languages. You can choose to focus on the bad things, and J2EE was a sad part of the language's lifetime.

The java code I write today has nothing in common with the java code I wrote 5 years ago. I do not believe I use a single library that I used 5 years ago. The reboot has happened.

And although I am also a C# programmer, I think there is great value in moving slowly too. Just crazily adding features is not necessarily a good thing.

Answer 11

Well, I have to say, regardless of whether the C#, Scala, or Groovy fans would like to agree or not, I think some of the suggestions here are completely daft.

1) Anyone who makes the mistake of calling Thread.run instead of Thread.start should NOT be programming. Here the programmer is at fault not the framework or language.

2) Disallow overloading? Why, why on earth would you do this. Again this makes no sense, what problems does it cause? I find overloading very very useful in any number of scenarios.

3) What is the real difference between factory methods and constructors. This is what constructors are, they are factory methods that create instances of the object. If you want or prefer factory methods, then IMPLEMENT THEM...not hard

4) == invoking equals(), operator overloading is one of the worst ideas to ever come in to the domain of object orientation. Do you realise how complex C++ programs can become with an array of overloaded operators. Its not obvious, and requires time consuming analysis.

5) Java would completely die if deprecated methods were removed. Why not just ignore them? Every language is heading in this direction, no language is perfect and mistakes can only be deprecated if developers are to continue with it and upgrade.

Although some of your comments make sense, I find that inexperience tends people twards principles and ideals and with experience you realize that pragmatism is what matters. Why is making Java perfect what matters, surly its what you can do with it. I see closures, reified generics, and properties as the only fundamental enhancements needed.

Java is not a toy for recreation, its here and popular because businesses are build on it and rely on it.

Answer 12

Do you agree that a reboot of Java (a new version breaking compatibility with old code) will be a good thing?

No, at least not without a migration path. Leaving your customers out to sea is a really bad idea. Educating them (particularly about deprecation and what that means) and encouraging them to move toward the new practices (maybe by offering code clinics for example) is important. Another example (probably more effective) is to continue to support legacy code with a service contract (something I thought Sun was doing anyway).

What are your pet peeves, things you believe need fixing in the language? My own examples focused on compability-breaking items -- things you just can't do in current Java without breaking existing code. But other ideas are also welcome.

Steve Yegge once referred to Java as the "kingdom of nouns" and I have to agree with him. I understand the reason for it, but over the years having to call "setters" and "getters" and the like has made code huge and noisy. I also think literals for lists, maps, regular expressions and XML are long overdue. Things could be a lot more cumbersome--Java could have been rolled out without String literals. Think about what that would be like.

I don't believe that the language needs new constructs such as closures. Some have argued Java has that already with anonymous inner classes. They are "noun-y" closures. It would be better if the Java Platform (the JVM) were fixed so that OTHER languages that run on it can move in that direction.

Answer 13

Most of the items you've mentioned are easily controlled by the developer which I think is good.

We may go through the complete list but I think the first items will do.

Drop all deprecated items. It's high time Thread.stop and friends, for example, will die.

Just don't use them.

Disallow overloading. It was a mistake. (I know this one is a bit controvertial, and yet...)

Don't overload

Constructors must be private, only. Static methods should be used as factory ....

Make all your constructors private.

Etc. etc.

The good point is that most of your have the choice to enforce all these items internally ( with each development team ) rather than changing the whole language and braking all apart.

I think a good refresh is needed but for different reasons, none of which are in your list ( closures for instance ).

Probably not modifying Java language, but supporting more and new languages like Groovy, Ruby, Python ( JRuby or XRuby , Jython etc ) and enhancing the JVM each time more.

I am tremendously happy with the fact I have upgraded a legacy webapp system and increase the performance only by changing the JRE from Java 1.2, to 1.3 and 1.4.

Answer 14

Disallow overloading. It was a mistake. (I know this one is a bit controvertial, and yet...)

Not using overloading is IMO a bigger mistake that leads to less maintainable code. For example have a look at this page from OpenGL API. (C-language, no overloading) glColor

Make good use of Enums in the library -- curerntly, a lot of older classes use int constants instead.

Is something broken because of int constants?

No offense, but this and most of your points sound just a bit obsessive compulsive instead of practical use of coding time. Good developer can already work around these things or refrain from using a feature that is not considered good. Also if a library already works, there's no reason to change it just to "use enums" etc. Throwing away good debugged code is a huge waste.

Considering "reboots", here's a link to Joel of Software text on rewrites from scratch. Not 100% relevant but a bit anyway :) Things You Should Never Do, Part I