Following the final approval vote for Java EE 6 last week, Sun has today announced the official release of the Java EE 6 SDK, along with GlassFish version 3, the first application server with full support for the platform, and NetBeans 6.8.
When the Java EE 6 specification was first made public the three central themes could be summarised as improving extensibility, adding profiles and pruning redundant APIs. EE 6 has delivered something on each of those areas. For extensibility the CDI portable extension SPI in particular offers substantially easier integration of additional technologies into the Java EE environment. For profiles the specification provides a general definition and introduces the Web Profile, defining a smaller container comprising a subset of key components such as servlets, JPA, JTA, JSF, CDI and EJB Lite. The pruning work has seen largely underused features like EJB Entity beans, JAX-RPC, JAXR and Java EE Deployment marked as future optional components.
At the same time, EE 6 has overhauled key parts of the platform and continued to push on the ease of development work which started with Java EE 5. As the platform is officially launched I talked to Sun Microsystems' Roberto Chinnici, one of the two leads for the EE 6 specification, beginning by looking at the significance of these themes from a developer's perspective.
Chinnici: The two initiatives that will benefit developers the most are the renewed push for ease of development in the web tier and the introduction of profiles.When thinking about "ease of development", most developers identify it with the introduction of an annotation-based programming model. While we did just that with respect to servlets in Java EE 6, there are many more features that together contribute to simplifying the development of web applications. We have new, powerful but easy to use APIs like JAX-RS, but also improved ones like JSF 2.0. We also added standard APIs for validation and dependency injection which are usable across all tiers. Just as importantly, we simplified the packaging of applications, for example by letting you put EJB components directly inside a web application and by making descriptors optional. The overall effect from all these changes taken together is that the amount of code in your application goes down, and so does the number of external libraries you have to bring in to get all the functionality you need to develop a complete web application.
InfoQ: What are the key new APIs and updates in EE 6? Are there any particular features that you are really pleased with?
Chinnici: It's a pretty long list. In terms of new APIs, the main ones are JAX-RS, Bean Validation and Contexts and Dependency Injection for Java EE (CDI). Additionally, all the major APIs already in EE were updated: Servlet, EJB, JPA, Connectors, JAX-WS and more.I'm very pleased by the form that some of the new APIs took, e.g. JAX-RS. I believe we managed to strike the right middle ground between making an API powerful and keeping it simple. It's an API that scales well from beginners to experienced developers, and from simple projects to complex ones.
One element that I've been paying a lot of attention to is how all the components of the platform work together. In this respect, I'm quite satisfied that in Java EE 6 we managed to break down a lot of barriers between APIs, most of which were historical anyway. We also introduced technologies like CDI that have the potential to become the common foundation for all future Java EE applications.
InfoQ: How will you judge if the web profile is a success?
Chinnici : Adoption. Of course, developers will truly embrace the web profile only when vendors start shipping products that implement it, but I think that the very existence of the web profile will attract new vendors to the field. Considering that all of the APIs in the web profile have open source implementations, and often more than one, it's not too difficult for a servlet container vendor to start offering a web profile product. I look forward to the day when Java web developers will be able to target a richer platform like the web profile in their applications, instead of plain servlet containers.
InfoQ: How do you balance the need for backwards compatibility with pruning?
Chinnici: First of all, according to the pruning process it takes two releases before any technology is made optional. This gives plenty of advanced warning to developers that they should stop using certain APIs. Then, once a technology has been pruned, it is still fully specified and retains all the compatibility testing that it had before, so that any vendor that ships it must do so compatibly.
InfoQ: How does Java EE 6 make it easier for developers to mix and match different components, frameworks and languages within the platform?
Chinnici: As part of the "ease of development" push in the web tier I described earlier, we introduced a way for libraries in a web application to self-register. This takes all the complexity out of configuring a framework. In most cases, we expect this self-registration to happen declaratively using a web-fragment.xml descriptor, but there is also the option to perform registration programmatically at application startup. This option is particularly interesting for scripting languages, because it lets them hook into the container in a fairly deep way. We validated the design of this pluggability facility in the web container on a variety of frameworks and libraries, so we are confident it will serve us well in the coming years. I should also mention that CDI has its own powerful extension mechanism that framework implementers can build upon. In effect, we abstracted the notion of a "bean" and formalized it into the SPI in CDI, so that extensions can create beans potentially out of thin air and register them with the container. Again, this is a very open-ended mechanism, with the goal of future-proofing the platform by making it possible to add substantial behavior to the container via extensions.
InfoQ: What is the most important design lesson you've learned in your years as a key architect for Java EE? What do you consider to be the biggest design mistakes in Java EE?
Chinnici: That an API should "say it as it means it".When you're designing an API, it's not time to be clever, and especially not clever for its own sake. What looks clever today, inevitably ends up looking tired two years from now. It's better to keep things simple and make sure the intent of any API you design is transparent.
It's hard for me to find *the* biggest design mistake in EE. It's not that there aren't things I don't like -- for example, the original use of JNDI. The issue is that, having been through this process several times now, I know how hard it is to find good solutions given all the constraints. I actually think that most of our critics, had they been put in the same situation, would have made the same decisions. So I tend to be more appreciative of all the *good* things that went into the platform, usually because somebody went the extra mile to make it happen.
InfoQ: Has Open-sourcing Java affected the evolution of Java EE?
Chinnici: Definitely. There are multiple open source implementations of every Java EE API. This creates a very dynamic community of implementers and users alike, and their feedback helps us select good ideas and bring them up for standardization as part of the platform. We can also float ideas we have in open source, perhaps as a non-portable add-on to one of our implementations, then based on the feedback decide whether to include it in the next release of the corresponding API. One recent example is the Jersey client API, which will likely end up in the next version of JAX-RS. It's a very healthy interchange.
InfoQ: What do you see as the future direction for Java EE?
Chinnici: In the short term, I expect profiles to keep us busy for a while. The web profile is a good starting point, but we haven't even scratched the surface of what's possible with profiles. The rules that govern them are very, very general -- they mostly deal with preserving compatibility to allow code and skill reuse across profiles -- so the Java EE community have a lot of freedom in deciding which profiles to define and with what contents.Also, there are big directions for Java SE that will help shape EE. I'm thinking of modularity and closures, for example. In my mind, Java EE developers are first of all Java developers, so the Java EE platform should take advantage of new features in SE to enhance the day-to-day experience of Java EE developers.
Finally, it's become increasingly clear that the Java platform is not only about the Java language. There is a sizable number of languages whose implementations on top of the Java Virtual Machine are now mature, I'm thinking for example of Scala, Groovy and JRuby. I think that Java EE will become more and more friendly to those languages; after all, that's one of the best ways that we can future-proof the platform.
As well as Sun's GlassFish server, JBoss are working on an EE 6 update for their application server and have released the first milestone release of AS 6.0.0 which includes support for CDI, JSF 2 and Bean Validation. For IDE support IntelliJ IDEA 9, which JetBrains also shipped this week, includes editor-level support for EJB 3.1, JPA 2.0, Servlet 3.0, JSF 2.0, CDI, Bean Validation and integration with GlassFish 3. NetBeans 6.8 supports incremental deployment with GlassFish version 3, and has editor support for JSF 2.0/Facelets, Java Persistence 2.0, EJB 3.1 including using EJBs in Web applications, and RESTful Web services. Sun has also created a plugin for Eclipse to allow it to support GlassFish version 3, and a tools bundle can be downloaded here.