In light of some of the recent discussions about potential enhancements to the Java language, there has been general concern that the Java language will get too complicated and will be filled with esoteric features that only a few people want and will use. As stewards of the Java Programming Language, we welcome such discussions and highlight some proposals here. See For More Information for links to alternate views and sources.
Curling the Chip
There was an excellent story in The Economist a few years ago about innovation. One of the points was to contrast innovation in new products and in established products. A wholly new product has no customer base, no commitments or expectations. So successful innovations tend to be big new ideas, or a disruptive application of an old idea in a totally new setting, like the Sony Walkman was.
Innovation for established products is arguably more difficult: You have customers who already like your product who you want to keep. There are teams of people building, delivering, and selling your product that would be difficult or expensive to change. So your ability to innovate is much more constrained. "With a successful technology like the Java Platform..., we need to scan the horizon for the metaphorical curls in the chip - non - disruptive innovations that have widespread useful consequences. "
But the article described the example of a company making potato chips that were popular, but not popular enough. Rather than invent some wholly new potato-based snack, they put a curl at the end of each chip. There was minimal disruption to their production processes. Customers didn't notice anything new until they opened the bag. There are two happy endings depending on your perspective: people loved eating them because they could shovel more dip onto them; people loved serving them because there was less spillage of dip after the party was over. Either way, sales jumped dramatically.
So, to some extent, with a successful technology like the Java Platform, Standard Edition (Java SE), we need to scan the horizon for the metaphorical curls in the chip - non-disruptive innovations that have widespread useful consequences. Given that many Java developers are Java Platform, Enterprise Edition (Java EE) developers, for example, it is no wonder that the use of annotations has been such a big hit. That curl in the chip has helped scoop up a big wobbling dollop of complexity out of the Java EE deployment descriptors and programming model.
Principles for Evolving the Java Language
Have you ever wondered why some cars are instantly recognizable? Seen a new BMW in the last 25 years without twin headlamps? Wondered how an SUV can still look like it's a Porsche? How a Corvette can still convey "Corvette" after over 50 die-hard 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 can explain why.
So what is it about code written for Java SE 5.0 - the release where we evolved the language in several ways - that makes it recognizable as the "same" Java you knew in JDK 1.2? (Only with some special sauce added.)
Just like the twin headlamps of BMW cars, the original design team and successive teams have followed certain design principles for the creation and evolution of the Java language.
Reading is more important than writing
One of the principal tenets is that it should do what you would expect it to do. There may be some developers who manage to produce fully formed and perfect code, ideally written for any future circumstance. When they are not walking on water, I guess. But for the majority of us, code is something living that we (or someone else) will need to revisit many times in what we hope to be a long and productive life.
One language, with the same meaning everywhere
No flavors, dialects, slangs, pidgins, or creoles allowed! One of the chief advantages of the Java language is that whether it be written as part of an applet or a desktop application, or to run an algorithm on the world's largest search engine, it still means the same thing.
If the semantic model of a language is clear - if its rules are simple and precise - the language will be more productive to use. Less is more. 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, to waste an afternoon on.
Over the course of a number of generations of evolution, you may see the link between only one generation and the next. A car's 2006 model may bear little visual relationship with the 1990 model. You only need look at C++ with its surfeit of features, each added no doubt for excellent reasons individually but collectively adding up to a big old heap of complexity. It was evolving under a different design principle ("more is less"?) before its Java-like successor (C#) appeared on the scene. "If we choose [our design principles] wisely, these will keep us classic and yet hip for a long time to come."
Of course, since Java's first release, the world has changed. In 1995, the predominant language that developers learned was C. In wrapping high-power concepts like garbage collection, object orientation, and concurrency into a language with a C-like syntax, Java managed to appeal strongly to C developers. But in 2007, such concepts have become so "last decade" (ironically, as in fact they originated with flared trousers and predate the war between Betamax and VHS). A new generation of developers has started with Java, rather than ending up there. One of the many interesting challenges for the Java language is how much to appeal to developers who additionally experiment with new dynamic languages like Python or Ruby, without having Java turn into a compromised superset of all of them.
A factor in the Java language's longevity will be the relevance of the design principles we use to evolve it. If we choose wisely, these will keep us classic and yet hip for a long time to come.
Many Potential Enhancements.
Over the years we have accumulated a large number of proposals for enhancements to the Java language. It is a fascinating task for the team here at Sun to work through the proposals and see how, both taking the proposals individually and in combination, they could continue to make the Java language productive and desirable to learn. Over the coming months, we hope to bring a proposal to the Java Community Process, but for now let's just highlight a small number.
The Java Beans property pattern has become a common programming practice for developers in a wide range of applications, from desktop applications, to EJB and web service components. There is a wide range of proposals to provide language support to streamline this design pattern.
Closures, Block Constructs, Method References
One of the hottest topics in recent years has been around adding full closure support to the Java language. Some have argued this is a natural and powerful extension to the language, while others have put forward other proposals that tidy up the syntax of the existing inner classes, and allow some limited extension of Java block statement, or allow for easy method callbacks.
Operator Overloading Related Ones
Just as hot a topic since the early days of developing the language has been that of allowing developers to provide custom implementations of the primitive operators in the Java language. There is a range of proposals from the hands-free, no-holds-barred ability to define the behaviors of operators operating on developer-created Java types, to more modest proposals to allow a limited form of overloading for classes like BigDecimal, or that allow the use of the array access operator on Java collections, or even allow the comparison operators to operate on Enums.
Aside from the more high concept proposals, there are smaller changes that often derive from developers who simply find that there is something they thought would work with an existing feature, and that doesn't. Such proposals include the ability to use strings in switch statements, multiple annotations, and so on.
Some of you may find that language discussions quickly become too abstract and esoterical. Luckily for those of you who would rather roll up your sleeves and try it out, we have set up a new project on java.net called the Kitchen Sink Language. The goal of this project is to provide experimental implementations of a large number of language proposals, in the form of experimental compiler builds and sample code. We plan to use this project as a way of getting the proof in the pudding before we have to eat it and bake it into the platform forevermore.
The Latin scholars reading will already know that Eadem Mutata Resurgo means "I shall arise the same, though changed". For Java SE 7, we are pursuing a small package of language additions that will continue the tradition of enhancing the Java language, while leaving its essence intact. We hope you'll enjoy using it as much as we enjoy creating it.
Related Online Articles:
No comment yet. Be the first to post a comment.