Do we need a Java++?

Question

It seems to me that, in some ways, Java is where C was a while back. Both are fairly minimalist languages for their time, with relatively clean, simple cores to build on. (I'm referring to the core language here, not the libraries.) Both are/were extremely popular. Both are/were lingua francas, with tons of legacy code. Both are/were lacking several modern productivity features that programmers from other languages often miss. Both seem very inertia-dominated and slow to adapt to a changing world.

It seems to me like it would be reasonable to create a Java++ that's roughly a superset of of Java, as C++ is to C. Such a language would attempt to lift Java out of the relative stagnation it's undergone, break backwards compatibility only in a few minor ways only if absolutely necessary, add lots of modern features that plain old Java is missing, and worry about standardization later. Features that might be a good idea include:

1. First class functions, delegates.
2. Closures.
3. Static type inference, similar to var in C# or auto in D.
4. Operator overloading.
5. Structs as value types distinct from classes, like C# and D.
6. Properties.
7. An option to ignore checked exceptions.
8. The ability to declare more than one top-level public class in a file.
9. More powerful builtin arrays that allow things like appending.
10. Better generics/real templates.
11. Something like the dynamic keyword for C# 4.0 that allows duck typing when necessary in a generally static language.
12. Since Java is primarily a VM language, maybe some hardcore metaprogramming features like generating code on the fly for certain things.

Do you think there would be demand for such a language? Do you think such a thing would succeed?

Edit: I'm not talking about compatibility at the runtime/bytecode level, I'm talking about compatibility w/ Java at the source level. Also, yes, Java 7 could add some of these, but it seems like the "official" process for adding features to Java is extremely conservative. The real point is the idea of forking Java into a branch were the focus is on innovation more than stability/standardization.

Answer 1

Like, say, Scala or better yet Groovy which bills itself as a dynamic version of java?

Answer 2

Wouldn't such an effort by Sun simply be called Java 7 (or 1.7 or 2.0)? Wouldn't such an effort by some other person/group be called something other than Java?

Answer 3

Check out the information that's available on Java 7. I think you'll find it is scheduled to add several features everyone is asking for, most notably closures.

Answer 4

If you were going to make big changes, wouldn't you want to start over again? There's lots of things that could do with fixing/removing in Java. You can't consider features individually - they do interact in unexpected ways. A big and complex language is probably a bad language (see C++).

Answer 5

If you add support for those structures to the JVM (where necessary, e.g., closures), and then create the necessary syntactic sugar in the written language and compiler. Of course if you wish to retain backwards compatibility then you have design decisions to make, which is why the Java Generics weren't as good as they could have been. You would want to break free of that to get a more perfect Java I think, but there would be very little demand because compatibility is where it is at.

And 7 can go straight away. We're not running up against FAT12 file limits on a floppy disc here.

Answer 6

I think the answer to "Do we need a Java++?" depends on who "we" are (and I'm not sure that "we" are all instances of one class ;-). This issue has been discussed on more than one occasion by The Java Posse.

Large corporate users of Java have a tendency to be more conservative. They have large development staffs and large bodies of existing code. As a consequence, there is a high perceived cost and risk to changes in the language or libraries (training, maintenance, breakage of existing code, etc.).

On the other hand, there are lots of small, light-on-their-feet dev teams (open source or otherwise) that are always ready to latch onto the Next Great Idea in programming. It's not clear to me that a single answer will leave everybody sufficiently satisfied.

I suggest that the growing ecosystem of JVM-based languages may help address this tension. If newer languages (Scala, Fan, JRuby, JavaFxScript, etc.) provide the notational features (and novelty) that the second group desires, while maintaining interoperability with existing Java (which can move at a more sedate pace), perhaps both groups can have their chosen flavor of cake.

I'm a little baffled by the degree to which some folks seem to want One True Language. Back in the day, it was quite common to hear the idea that each language (notation) had a "sweet spot" of applicability; sometimes the right solution was to write each part of a system in the appropriate language and link them together.

Back to the future, anyone?

Answer 7

Those things are mostly fluff.

You need to solve some bigger issues like making concurrent code easy to design and reason about.

Answer 8

Going to get downvoted by the Java fanboys for this but as someone who writes both Java and C# I'd say that C# is as close to Java ++ as you are going to get.

C to C++ was a paradigm shift, from procedural to Object oriented, the only reason they retain the name is to woo C programmers into thinking that it was the same language which led to a load of really bad C code masquerading as C++.

Java is constantly expanding and Sun are quickly incorporating more and more features, so it could well be that Java 7 or 8 is your Java ++

Answer 9

As java is becoming open source, you can take the source(if it is all available) and make your own version of java. If this gets wide scale adoption then great, if not then it may not be a set of features that are needed.

Answer 10

Java can and should be improved, but I don't think that there needs to be one language to fit all needs. This is generally a bad idea, much like the death star.

A lot of programmers are just lazy and don't want to learn new things. They rather stick with the one language they've been using for the last 10 years.

If you need speed and more control over your hardware, you use something like C. If you need system administration tasks, you probabely end up with shell scripts or a scripting language like perl, python or ruby. If you do a lot of math specific stuff, Matlab is a good choice. Etc. pp.

Use the best tool for the task, no matter what language it might be. A good programmer should be able to work with any language (As for me, I'm still working on that).

Answer 11

The question is really how you decide what goes in the "next language". Just adding/removing features piecemeal will result in a bunch of crap. It's much better to think about how the addition or removal of those features (often working in combination) change the way you program according to new principles. For example, I thought it was interesting that the Java closures proposals suffered in many ways from having to deal with static typing without rich type inference. There are copious examples of dynamic languages with pretty closures - those go well together. And Scala and other languages have shown that static typing plus rich type inference can also make closures pretty. My point is that taking language X and making language X++ is probably not that interesting. It's more interesting to see problems in X and make new language Y.

There's certainly nothing preventing you from forking Java now and making it into whatever you want (as long as you don't call it Java or want to pass the test suite). As mentioned above, there are already a set of exciting high-quality languages doing just that and maintaining interoperability with Java now. I'm thinking primarily of Groovy, Scala, Clojure, and Fan and less of ports of prior languages to the JVM like JRuby, Jython, and Rhino which tend to have a more challenging time implementing clean Java integration.

It's quite likely that the JSR 292 features coming to the JVM in Java 7 will provide an even richer playground for language development on the already superb JVM base. And the CLR+DLR are also pushing many interesting boundaries.

More and more, I think the future is going to trend towards picking the right language for the job. That's either going to happen in languages with a blended tradition (Scala is a good example of FP / OO for instance) or in virtual machines (JVM, CLR, BEAM, Parrot, whatever) that foster clean integration between multiple languages. Or most likely, both of these. I think we are NOT trending towards any one Next Big Language that is a derivative of Java (or anything else).

Answer 12

Currently in Java there are workarounds for many of these, which does make it harder to introduce more natural ways of doing these things.

1. First class functions, delegates.

Most cases are shorter using reflection. (But less natural)

.4. Structs as value types distinct from classes, like C# and D.

This I would agree with.

.5. Properties.

This can be done now, but some effort is required. Proper builtin support would be better.

.6. An option to ignore checked exceptions.

You can do this now, but its a hack. Note: checked exceptions are a compile time feature.

I am rather sceptical that this is really a good idea unless people really understand exceptions. Often people who suggest this don't like being forced to think about error conditions, documenting or handling them.

.7. The ability to declare more than one class in a file.

You can do this now. Just not more than one top-level public class.

.8. More powerful builtin arrays that allow things like appending.

See commons ArrayUtils. An array which has a sane toString() would be start.

.9. Better generics/real templates.

I agree, depending on what you mean. I think they should get the current implimentation to work first, before improving it. e.g. So the Java APIs can be compiled without unchecked warnings.

.10. Something like the dynamic keyword for C# 4.0 that allows duck typing when necessary in a generally static language.

Again, reflection does this, but its relatively ugly.

.11. Since Java is primarily a VM language, maybe some hardcore metaprogramming features like generating code on the fly for certain things.

Like JavaCompiler (In java 6), Scripting support (In java 6), JCI or BeanShell.

Answer 13

C++ is object oriented C. Java is already object oriented, so how would we go about another paradigm shift, making it Java++?

In a way I think it is the other way around. Java is way ahead of C++. Java has high level libraries and frameworks, whereas C++ very often still is low-level and intermixed with ansi C (because we can).

Java has good unittesting possibilities, and large communities which are all pointed at the same direction.

Having more "features" does not make a language better. I think it is possible to make it worse.

In the end, putting one language "in front of" the other is not going to help. Select the best tool for the Job. I think Java as a language is pretty ok as it is. C++ however could use some better libraries, like a port of Spring for instance.

Answer 14

I actually really agree with your sentiment, having run into issues with Java that could be alleviated by your suggestions.

In principle, you could write your own javac that works for this and uses the existing Hotspot JRE. However, you really can't make that happen without Sun's help.

The problem is really twofold: 1) Sun's approach is to support the "Java platform" and is resistant to a new standard, even a superset and 2) to get any change to Java, you have to get a JSR issued -- and that usually requires a corporate sponsors. The corporations tend to have other priorities.

Then again, I would urge you to push for it. After all, until 2007 many smart people almost remade Java from scratch = GNU classpath. So there is the requisite talent for a "second first-class JVM language."

Answer 15

I suggest to have a look at Beyond Java.

There a good review on Joel on Software.

Answer 16

As much as I do feel that Java has become outdated, the truth is, I think we all know that as a language it still works pretty well. Sure, a lot of the newer stuff that we can find in other languages aren't there, but it still works! You can still do everything, it just sometimes takes longer and takes more work. I am definitely looking forward to the day when it's superceded, but I just think that with all the existing code and applications that are written in Java, there's just no way at the moment, (almost) no one would make the shift to Java++. I think we're waiting on a real paradigm shift, like C++ was to C. Perhaps functional programming could be the next big thing and Scala will be the next Java.

Answer 17

Java++ is already here... :D