Principles for Evolving the Java Language
By dannycoward on Mar 06, 2006
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.
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 ? ...