Debate: Should the Java language stop adding new features?

The one thing that really puzzles me is: why is everbody insisting that Java needs/requires backwards compatibility? I don't think backwards compatibility should be maintained at all costs. To me, the goal should be to design a language that's tight (i.e. readable), elegant, and efficient (in terms of productivity).

In my opinion, Microsoft did the right thing when designing .NET 2.0 - abandon backwards compatibility in favor of implementing new features completely and correctly. They were consistent enough to "drill out" the type system and runtime. Consequently, C# generics just work the way you would expect them to. C# 2.0 just feels very natural.

In constrast, Java generics are basically useless - for all but the most trivial cases, you're stuck with compiler warnings, lots of artificial casts, or you simply can't do things the way you wanted to. Generics are a great thing if you can actually use them. In C#, you can. In Java, you can't.

I don't understand why Java generics have been implemented that naively. Everybody should have realized that type erasure won't do the job. So I don't take the argument that in order to "not let a disaster like generics happen again, we won't add any new features to Java".

I would strongly advocate adding some missing features to Java, and implementing others (i.e., generics) correctly. Java is a rather primitive programming language. Yet I fear that Sun won't ever take that route.

regards,
Karl Traunmueller

Another thing that comes to mind is the type system. Take numbers for example.

In Java, you can't directly assign an Integer to a Long, which is what you would naturally expect to work. Integer and Long derive from Number, but there's no way of smooth conversion between numbers (aside from the artificial intValue/longValue).
In C#, you have conversion operators (and operator overloading in general, which Java doesn't offer), and the compiler can convert between number types in a very natural way.

regards,
Karl

Yes to me its not so much adding features as fixing things and implementing things that SHOULD have been there from the word go. If that means some cost of backward syntax compatability, so be it. Other suggest leaving it and "moving on" to a "main" language for the VM (eg scala) which would also be fine if enough people want to do it too (as it achieves the same end). But the VM and the language still have branding association, so it would seem a shame not to fix up the "flagship" language.

Java is a statically typed language without meta-programming features. If it's not in the byte-code it doesn't exists.

The JVM can support meta-programming on existing byte-code and duck typing, see Groovy.

There's probably an opportunity to create a version of Java that breaks backward compatibility on the byte-code level (for example, adding methods to java.util.Collection) but this will be a language separate from Java.

Since we already have those - Groovy, Scala - it seems that those that limit themselves to the Java language will have to accepts its idiosyncrasies. However, those same people can combine Java with other languages on the JVM: Groovy, JRuby, Scala, ...

Maybe it's time to give up this fetish with the Java language and embrace the richness of the Java Platform.

Maybe it's time to give up this fetish with the Java language and embrace the richness of the Java Platform.

Java must support XML as a first class datatype, and not just with clumsy libraries like JAXB (patience, no flames, please!). We need a "java.lang.XML" datatype, so that we can do in Java what we can do, for example, in JavaScript with E4X.

With increased SOA thinking (whether SOAP or REST), there is more emphasis on XML as a language to abstract and represent the interface to encapsulated domains, more emphasis on XML as a data interchange language between such autonomous domains. Java has now hunkered down to be more of an implementation language _within_ a domain, and in a SOA world, it needs to be able to handle its interactions with other domains better, i.e., it needs to handle XML much more elegantly and naturally.

Contrast the elegance of this E4X example (which "mashes up" two XML documents) with anything currently possible in Java, and you'll see what I mean:

<html>

<head>

<META http-equiv="Content-Type" content="text/html; charset=UTF-8">

<title>Mashup Demo (Pure content aggregation)</title>

</head>

<body>

<script>

/*

Grocery list with items and quantities only (e.g., my shopping list)

*/

var gList = new XML();

gList=<service-response>

<list>

<line-item prodid="tomato" qty="4"/>

<line-item prodid="potato" qty="3"/>

<line-item prodid="onion" qty="6"/>

<line-item prodid="chilli" qty="40"/>

</list>

</service-response>



alert ( "Raw shopping list\n\n" + gList );



/*

Grocery unit prices (e.g., supermarket prices)

*/

var gPrices = new XML();

gPrices=<service-response>

<prices>

<prod id="potato" unit-price="10.00"/>

<prod id="tomato" unit-price="20.00"/>

<prod id="onion" unit-price="30.00"/>

<prod id="beans" unit-price="40.00"/>

<prod id="chilli" unit-price="0.50"/>

</prices>

</service-response>



alert ( "Grocery prices\n\n" + gPrices );



/*

Mash up the two pieces of content to produce an augmented grocery list with
individual costs and total cost

*/

var total = 0.0;

for each ( i in gList.descendants("line-item") )

{

i.@amount = i.@qty * gPrices..prod.(@id==i.@prodid)["@unit-price"];

total += Number( i.@amount );

}

gList..list["total-amt"] = total;



/*

Display the mashed-up list

*/

alert( "Mashed-up shopping list\n\n" + gList );

</script>
</body>

</html>

BTW, that example only works in Firefox because of its native E4X support. Apologies to IE users.

Ganesh

I like Joshua Bloch's argument best: there is nothing wrong with adding new features so long as they have a good power-to-weight ratio.

There is no need to freeze Java's features. Nor is there need to stuff the entire kitchen sink into it.

Deprecate some stuff. Put them in jar files that you can include if you still need it. Make Java more modular. Fix what is already broken and smooth out as many warts as you can. Focus on ringing the last ounce of speed out of the VM. Enhance the VM mechanism (multiple loads, better for others to plug into).

This is a critical discussion which will clearly have ramifications for the software development industry far outside of the current context of Sun and Java.

1) Backward compatibility serves Microsoft well enough for them to suffer (or is it inflict upon it's users?) the inevitable problems which come with it for one very good reason. They are currently a virtual monopoly in the desktop OS and productivity suites market - and if they break backwards compatibility and are forced to compete with themselves they will open the market to other competitors. Is that the case for Sun? No, they are competing in a very aggressive market again (at least) DotNet and RoR (if not LAMP and others). I think that Sun is insane to place such a high premium on backwards compatibility in such a competitive market when the other options will start to look better and better over time. This is why MSoft is so happy to forgo backwards compatibility with DotNet but not with Windows or Office.

2) Clearly generics are a disgrace. I have made it a point to use them correctly as best as I can understand them and am continually surprised by them. I remember the STL in the 0.2, 0.3 days and it reminds me of that (but with much better error messages!). Still people are missing a point about it. It wasn't backwards compatibility with the Java language that limited the design, it was backwards compatibility with the JVM itself, which is a whole other kettle of fish! Would it have been worth it? Maybe. Msoft seems to version the DotNet runtime separately from the language and it doesn't seem to bother them. But generics (unlike closures but similar to continuations) are a much bigger change than any other as the whole platform needs to evolve.

3) I fear that Scala is just too complex for the masses (due to it's functional programming roots). Although I understand what I see with Scala, I just can't think of solutions to problems in a way which leverages it's power - a problem which simple closures in Ruby and Groovy do not suffer from. I think Scala should be officially 'adopted' by Sun like JRuby (same with Groovy actually), but I think it's a mistake to push something so advanced as the mainstream approach.

4) Having said that, of all the changes ever proposed for Java - a full closure proposal - one which would allow creation of new 'control statements' would be for me the single best change that could be made. Closures are a HUGE way to improve the quality of the coding. With a single change - although closures themselves may be hard to write (like generic classes) the senior developers on projects can make such plain abstractions for the access to the resources that the others need that code will be free of the badly handled exception/finally and synchronized blocks. It's HUGE! I don't care if it is in Java 7 (or lets say Java 1.7) or a new and shiny Java 2.0 - but I want it!

Cheers

I agree with Karl, I think he hit the nail with his post. Think of it this way: What if you had an application you started writing 15 years ago, filled with workarounds and hard coded stuff which just screams for not only refactoring but a genuine redesign. It's extremely complicated and it can no longer take more requirement changes - it's unmaintainable. Most will not see this scenario progress, it will have to be, at least partly, redesigned one way or another. Now why shouldn't this also be the case with a programming language? It's also just software!

Those who advocate freezing language evolution in favor of going to something new are missing the point.

The only reason to "stabilize" a language is if it is so hopelessly foregone that new essential features cannot be added in an intelligent way to the language. There is nothing inherently difficult about the Java syntax that would prevent new features from being added.

What backward compatibility?
C# did NOT break any backward compatibility when they introduced generics in C#2.0. You can run your old bytecode written on .Net1.0(and 1.1) DIRECTLY on .net2.0 without any recompiling or any modification. Microsoft solved this backward compatiblity issue by keeping both their generics and non-generics versions of all the classes in their SDK (i.e. they have both Dictionary and Dictionary<T,Y>). So the new .Net2.0 framework will still be able to run all your old non-generics .net1.0 libraries just fine.

When Java talked about "backward" compatibility, they were actually talking about "forward" compatibility. They were talking about guaranteeing that the old Java4 will be able to run the newer applications written on Java5. Silly. Silly silly goal. Even sillier, considering that in practice you normally won't be able to run your new java5-targetting-applications on java4 anyway.</t,y>