Conservativism in Language Design

One of the most interesting things about the development of Java 7 has been the open debate around language features.

However, one of the side-effects of that discussion has been a certain amount of visible frustration from some quarters about the pace of change. The process has been criticized for being too timid, too slow, too conservative by some people. There has also been rather a lot of vitriol over the scope or non-inclusion of specific features.

Language design is hard. It’s hard to think about all possible use cases for a feature up front. It’s even worse to try to think about how your language features will interact. Very smart people get this wrong. A lot.

Now stop and think for a minute about how successful a language Java is. It’s everywhere. There are at least 1 billion Java runtimes in the world today. Millions of companies deploying Java technology and 7-8 million Java developers worldwide. Stability and backwards compatibility is a huge deal.

Consider a largeish company with, say 100-1000 developers, which is introducing a new technology platform. Empirical / anecdotal data suggests this platform will probably be in use for 7+ years. Once enterprises start using a technology, it can be very difficult to get it out again. That same company will probably also spend around $2-3 million on tooling, support, etc over the lifetime of the platform within the company. Multiplying that up by the tens of thousands of such companies that exist, gives some idea of the dollar value of the corporate Java ecosystem.

Putting all of this together, and we can easily see how bad it would be if a misfeature in the language design was allowed to escape into the wild. Once a language feature is out there, the Java community basically has to live with it forever.

This is why the caretakers of the Java language tend to take the view that Java is not the right place for language feature experimentation. Every new feature interacts with the existing “feature surface” of the language, and often in surprising ways. The place we see this the clearest in Java is with the type system.

Looking at the changes in Project Coin, the new multicatch and diamond syntax features are the places where the type system is most deeply involved, and in the formal spec for each contains a large screed of type theory.

Once those features are out in the wild, any further change will now have to deal with the larger amount of type theory that now forms part of the language standard. This acts as a constraint on further language innovation.

All of this leads to a situation whereby change has to proceed slowly and calmly. Features aren’t added lightly – and the engineers who create them aren’t idiots.

Finally – if a new feature isn’t exactly as you expect, then stop, think, take a deep breath. Think about the reasons why the feature may not be precisely tuned for your use case – and about the inevitable compromises that the new feature may represent.

Language design, like legislation, can be more about tradeoffs, compromises and the art of the possible than is sometimes recognised. When combined with the engineering and project management constraints common to all software projects, the fact that we manage to get important new features out at all starts to look like a triumph.

There’s always scope for improvement, and the JCP could use more individual end user and JUG members. If you have strong opinions about new features, or want to be more involved – then this is a great time. With Java 7 just around the corner, and the work already underway for SE 8 and EE 7, this is your chance to make your views known. Early feedback from end users on proposed features is highly prized – you just need to get involved and start contributing.

From http://www.java7developer.com/blog/?p=246