Principles for Evolving the Java Language

Ever wondered why some cars are instantly recognisable ? Seen a new BMW in the last 25 years without twin headlamps ? Wondered how an SUV can still look like its a Porsche ? A Corvette a Corvette after over 50 years ?

Car designers, of course, follow certain design principles that keep the look of cars, especially their luxury brands, distinctive across multiple evolutions of a successful model. While we may not be aware of what these principles are as we see a new model Volvo pass us on the freeway, we usually know its a Volvo before we could explain why.

So what is that tells you the first time you Java written say for Java SE 5 Tiger, the release where we evolved the language in several different ways, is still the Java you grew up on in JDK 1.2, only perhaps with some new enticing special sauce added ?

Just like the twin headlamps of BMW, we have design principles for the evolution of the Java language.

I was looking through some older presentations in order to write a new one, recycler that I am, and I saw a presentation that Graham, Gilad and Mark made last year at JavaOne about the evolution of the Java language (find it using the keyword 'Evolving' here). Here are the design principles, together with my own commentary, we use as we evolve the Java language:-

Reading is more important than writing

That is to say the code should be a 'joy to read' (I'd be ok with 'short and sweet' myself) and it should do what you would expect it to do. I suppose in that parallel universe where you write your methods and classes just once and they work perfectly as you'd intended and never need changing ever ever again, then I guess this principle might seem a little redundant. But, hello, we don't live there, and we every one of us has particular methods that have burnt a hole in our hard disk because we just can't ever seem to let them alone. Declarative power rules ok.

One language, with the same meaning everywhere

No flavors, dialects, slangs, pidgins or creoles allowed ! The rain in spain falls most definitely on the plain.

Simplicity matters

Or in other words, if the semantic model is clear, the language will be more productive to use. Naturally, this creates an instant tension when considering a new language feature: adding a feature is in itself a new complexity in the overall scheme of things. Something new to understand, something new to trip over, waste an afternoon on. Also known as less is more.

You only need look at C++ with its surfeit of features, each added individually no doubt for excellent reasons but collectively adding up to a big ol' heap of complexity, to understand it was evolving under a different design principle (giggle, 'more is less' ?) before its Java-like successor was named up north.

Over the course of a number of generations of evolution, you may only see the link between one generation and the next. A car's 2006 model may bear little visual relationship with the 1990 model. There are of course reasons to have to change those principles over time if forced by circumstance. (Used Audi anyone ?).

A factor in its longevity of the Java language will be the relevance of its design principles we use to evolve it. I hope these will keep us classic and yet hip for a long time to come. Hmm, maybe like the new Range Rover ? Ooh, or maybe a Bentley Continental ? ...


Excellent post! One thing about readability: remember that even if \*you\* never go back and have to re-read your old code, others will most certainly read it. Which is why I don't want a short and terse language syntax.

Posted by Mats Henricson on March 07, 2006 at 04:51 PM PST #

The legacy baggage and compatibility promise of Java makes changes far harder and they usually integrate badly with the language due to these constraints. So what looks good on paper or during beta ends up as a rather tepid if not awful feature when implemented. But that is not really my main problem. Java has a HUGE following of people who like it, why risk it? There are thousands of features people are asking for, language changes don't rank high up within most of the feature requests I saw. Does Sun make surveys before picking a feature list or is there some meeting where JCP people sit in a room and brainstorm? How do you decide which feature to kill and which to promote? Why language changes, why now before Java ME has caught up? The decision making process seems opaque to me, which normally I wouldn't mind but in this case it seems opaque and contradictory to a significant segment in the developer population. Not that I would know since no one bothered surveying us to ask us how we want Java to be. So the process shouldn't be a democracy but why create controversy when you can provide features that should have been a part of Java many releases ago? (e.g. MVM, caching JIT, non-administrator users etc.).

Posted by Shai Almog on January 09, 2007 at 10:44 PM PST #

Post a Comment:
Comments are closed for this entry.



« July 2016