Java 5.0, released in September, 2004, was undoubtedly the most dramatic update since Java's inception almost ten years ago. It introduced a large number of new and highly anticipated features such as generics, annotations, type safe enumerations, and autoboxing. Since then, many avid coders have tried out these new features, often in their personal time and using basic examples from tutorials and presentations. Based on public commentary, initial impressions are typically quite positive.
Fortunately or unfortunately, the business world doesn't move nearly as quickly as enthusiastic developers would like. Even today, more than two years after its release, we still see few projects and products exploiting Java 5.0. At Eclipse.org for example, with the exception of a few rogue plug-ins, all major components have chosen only to add support for Java 5.0, instead of actually adopting and exploiting it in their implementations. In October 2006, that changed with the availability of the first EMF 2.3 build that requires Java 5.0. It was clear to the EMF team that the new features of Java 5.0 could be exploited to improve and modernize the APIs that EMF generates. But, as we began the work in earnest, we realized that the rabbit hole was far deeper than we had anticipated. The gamut of design possibilities opened by annotations and the subtle, intricate complexity of generics became daunting. Changing a heavily used API to exploit generics, while trying to maintain binary and source compatibility, proved to be a decidedly non-trivial task, and certainly not one for the weak of heart.
This long talk is a discussion about the experience of adopting Java 5.0 in
EMF. We will discuss the surprises, the issues that made us curse Java, the
arduous aspects of "generifying" our List implementations, and the
rationale behind some of the decisions we've made. We will also convey some of
the insights we developed to help retrain our coding intuition, such as the
subtle differences between
extends Object>. The switch to Java 5.0 requires a mental shift, as
assumptions are no longer valid. The eyes should catch even this innocent
looking line of code as a potential problem:
if (x != null) System.out.println(x.hashCode());
As we will discuss, depending on how
x has been declared, this
While preparing this proposal, we've questioned, as you well might, whether the JDT developers would not be better equipped to present the details of Java 5.0. It's quite possible they would, but our hope is to convey the concepts from our own pragmatic perspective and based on extensive use of the new language features. That said, the discussion will be deep, reaching the details of the byte code generated by the compiler, when necessary. On more than a few occasions, we've had to go there ourselves to understand what was going on.
This talk is aimed at anyone who uses Java on a daily basis and will be particularly interesting for those who are looking to exploit Java 5.0. This is not a Java 5.0 introduction course though; we expect a rudimentary understanding of Java 5.0. No experience with EMF is necessary; it is merely the context for our discussion and examples.
Marcelo is a software engineer for IBM Rational Software at the Toronto Lab. He has worked with Eclipse technologies since joining the company in 2000. In the last 3 years, he has been a committer on the EMF project, being responsible for numerous changes and new features. Prior to that, he was a committer for the Hyades project which is now known as TPTP. Over the last 6 years, he has presented workshops and tutorials in conferences such as OOPSLA and EclipseCon. Before joining IBM, Marcelo worked for a Rational partner, managing several projects using Rational's tools and processes. As a certified instructor, he taught various courses on object oriented analysis and design; requirement management; and functional testing.
Ed Merks is the project lead of the Eclipse Modeling Framework project and a co-lead of the top-level Modeling project. He has many years of in-depth experience in the design and implementation of languages, frameworks, and application development environments. He holds a Ph.D. in computing science and is a co-author of the authoritative "Eclipse Modeling Framework, A Developer's Guide" (Addison-Wesley 2003). He works for IBM Rational Software at the Toronto Lab.