Espiritu de Java

"It's more important that Java programs be easy to read than to write."
- Graham Hamilton,
Sun Fellow in the Java Platform Team, Sun Microsystems

We're starting to think about potential language features for Dolphin. I've been reflecting on the principles that James Gosling so brilliantly infused into the original Java language and which we've tried to preserve as it evolves. The core principle involves making programs easy to understand. The Java language is powerful but simple, easy to read, with a consistent, clear meaning. It's more important that Java programs be easy to read than to write. That may sound trivial, but it isn't.

Looking back at C++, there were a whole set of factors at work that make reading source code difficult: First, the C++ language itself became very complex. Many new ideas were added incrementally and, unfortunately, the seams show. Second, the C++ language consciously chose to emphasize "power" and "flexibility". That sounds nice initially, but, unfortunately, it also means that there is very little you can rely on and almost any simple program statement can have weird side effects. In C++ the statement "a = b;" must be approached with caution. Finally, the macro pre-processor reinforced the "power" aspect, but again at risks to comprehension.

The Java language took a very different approach through attempting to be an unobtrusive language. As a developer, you should be able to focus on what your application code is doing and on how it interacts with libraries. Code should do what it seems to do -- developers shouldn't need to worry about clever language side effects or about what "=" means this week.

This focus on clarity and readability has affected the Java language in deep ways. It has led to a focus on keeping the language simple and clear. It has led to fairly conservative uses of syntax and minimized the places where user defined code can modify base semantics. For example, there's a strong focus on having "one language" which means the same thing everywhere. A Java developer should be able to start reading a chunk of new Java source code and rely on a consistent set of language semantics. So part of Sun's investment in the Java language includes a strong focus on both a very precise specification (currently driven by Sun's esteemed computational theologist Gilad Bracha) and also an extensive language compatibility test suite.

Principles are good, but so are pragmatics. If we stuck too rigorously to our principles, we'd probably never dare make any changes to the language. It is natural for things to evolve, and we want to be able to make developers more productive, within the spirit of the language. But we are also very conscious that adding individually useful features may slowly undermine the deep values of the language.

Looking forward to Dolphin, I suspect we'll stay conservative on changes, as each change adds complexity. We're unlikely to add a macro preprocessor or any general form of operator overloading, or full-blown AOP, or any other mechanism for redefining and obscuring core semantics. But we will look for new language ideas that help developers with common problems. For example, one area I'm personally interested in is some kind of "friends" import mechanism to make large multi-package projects easier to manage.