 | |
With the launch of Java 2 Platform, Standard Edition 5.0, code- named "Tiger," we explored the innovations in J2SE 5.0 with Graham Hamilton, Sun Fellow in the Java Platform Team at Sun Microsystems. In Part Two of the interview, we asked him to provide a broader perspective on Tiger, Java 2 Platform, Standard Edition 6.0, Java 2 Platform, Standard Edition 7.0, and the long-term future of the Java platform.
Misconceptions about Tiger
Contributing to J2SE
For over five years now we've been using the Java Community Process to evolve the Java platform APIs. That has worked really well and a very broad community has contributed to Java API development. I would definitely encourage people to track the JCP, either by joining expert groups or by participating in public reviews. However, we've realized that many developers also want better insight into "where the rubber meets the road" in the J2SE source code itself. So we're working to make our development processes more transparent. As part of that, we're trying to participate more in online forums, in blogs, and in other discussion groups. In order to give people something to chew on, we're now providing regular snapshot releases of our internal builds, in both source and binary on java.net This is a very big change for us and it is rather scary, but we hope it will make it easier for developers to see and influence what we are doing.
Second, we have an enormous developer base. We'd like to engage with people, but we are also concerned that we are likely to get much more feedback than we will ever be able to accommodate. So we want to make sure that people have realistic expectations. We want feedback and ideas, but we won't be able to reply to every suggestion or accept every proposed fix. Many people want to make changes, but one of our toughest challenges is managing change, so that we don't break things other customers depend on. We're going to have to figure out how to manage this process as we go along. It will be an adventure! Tiger and Near-Term Java Technology
And over time, I expect we'll see some of those incorporated into Java 2 Platform, Micro Edition (J2ME). I personally think a lot of the language features are ripe for being picked up by J2ME almost immediately -- but I hasten to add that this is up to the J2ME community. Evolving the Java Language
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. Multiple Languages for the Java Platform
Risks to the future of Java Technology
There is always a temptation for each individual vendor to cut corners on compatibility. If someone can get their product out a little faster by skipping a few features or failing a few tests, I can understand that temptation. But we are all in this together. If each vendor cherry-picks the set of features that they want to implement, then we will end up with a fragmented platform where there is no real application portability. Fortunately, all of the major vendors understand the benefits of strong compatibility, but at the same time, no one wants to be unfairly disadvantaged. One of the strengths of the Java Community Process is that it has very strong requirements around compatibility which are binding on all participants. This helps reassure the vendors that they are all held to the same standards. So it may take work to achieve compatibility, but all participants face the same work. And as developers, this means we benefit from a wide range of competing, but compatible, Java implementations! See Also
|
| ||||||||||||||||||||
| |
| ||||||||||||
Print-friendly Version
What lessons have you learned in the process of creating Tiger?
It took us close to three years to deliver Tiger, so one lesson we
learned is that we were a little too ambitious and we should
probably have put in a little less and shipped it a little sooner. We'll
probably try to put a smaller set of functionality into our J2SE 6.0 and J2SE 7.0 releases so we can get them out
sooner. We're likely to move to more frequent, smaller releases, as
opposed to three-year big bang releases.
