Skip to main content

Ease of development in the Java EE 6 Platform

Posted by robc on November 14, 2008 at 5:20 PM PST

With all the talk on profiles and modularity in Java EE 6, it's easy to forget that the main, ongoing focus of the last two EE releases is ease of development.

Until Java EE 5, the main concern was making the platform more powerful and comprehensive, so that enterprise developers would have everything they need to get their job done. For example, over time we added several technologies aimed at expanding the number of enterprise systems a Java EE application server can connect to: JMS, Connector API, JAXR, web services...

The release of Java EE 5 was a watershed event: the focus moved decisively towards making the platform easy to learn and use for developers at all skill levels. This led to the addition of several new, annotation-based APIs sharing a common set of patterns: Enterprise JavaBeans (EJB) 3.0, Java Persistence Architecture (JPA) 1.0 and Java API for XML-based Web Services (JAX-WS) 2.0. Besides placing more of the information in the source code itself, the use of annotations greatly reduced the need to edit XML-based deployment descriptors, one of the traditional scourges of Java enterprise developers.

In Java EE 6, we plan to continue the drive towards a simpler, friendlier platform. This time around, much of the focus is on the web tier, but there are important new features being delivered outside it.

Web tier

Servlet 3.0 brings the annotation-based programming model popularized by EJB 3.0 to the web tier. Once again, the goal is to greatly reduce the need for editing the web.xml deployment descriptor.

But why are descriptors edited in the first place? It turns out that most web tier development is done using third-party frameworks and libraries, mostly licensed as open source. Each framework comes with a set of servlets, servlet filters and context listeners that need to be registered correctly for the framework to work.

In Servlet 3.0 we address this issue by introducing web.xml fragments which live inside library jars and contain a description of the infrastructure needed by the library to work. At application initialization time, the container will discover the fragment and process it as if it had been part of the web.xml descriptor. The end result is pain- and error-free framework configuration for all applications.

Of course, the servlet expert group went beyond the basic use case and thoughtfully added an API to programmatically register new servlets at startup. I mention this fact here because it underlines a core principle of the new, annotation-based model, i.e. that declarative means should be complemented by programmatic ones to account for advanced use cases. The same principle can be seen e.g. in JAX-RS, with its separate packages for the declarative API (javax.ws.rs) and the programmatic one (javax.ws.rs.core).

By allowing developers to structure their application as a set of resources, JAX-RS makes it a lot simpler to implement RESTful web services. As some people are quick to point out, JAX-RS cannot and does not by itself guarantee that your application will adhere to all the REST principles, but it's certainly a lot more productive way to reach that goal than the alternative of rolling your own HTTP-aware application code.

JSF 2.0 too contains strong ease of development features, such as the support for facelets as a page declaration language. I'd also like to thank the JSF expert group for their determination in improving an often overlooked area, that of the error messages emitted at development time. In many ways, Java EE has historically focused on fully tested, ready-to-deploy applications, but the truth is that most of the hard work happens before that stage is reached. Any help that we can give developers in their quest to be more productive is certainly worth the effort (this is yet another instance of the "always remember who your customer is" principle).

Elsewhere

As I mentioned earlier, ease of development improvements are not limited to the web tier. A lot of the work going on in the EJB 3.1 expert group is directed at making EJB development even simpler. Among the many features, I'd like to single out three.

The new singleton bean type captures an often-desired pattern in an easy to use form -- as you may have guessed there is an annotation for it, @Singleton. With optional local business interfaces we finally achieve the goal of defining an EJB component in a single class file, with no interfaces and no deployment descriptors. Although the path may have been circuitous, the end result is something to behold. Finally, embeddable EJB will make testing your code a lot easier and help expand the reach of EJB technology to all Java SE applications.

Although space doesn't allow me to go over every new feature in the Java EE component JSRs (my apologies to all the expert groups involved), I'd like to mention a few more contributions to the ease of development cause that span multiple technologies.

The success of the EJB 3 programming model has renewed interest in using EJB components in web applications. In this respect, EJB 3.1 removes a significant barrier by allowing EJB component classes to be packaged directly inside a web application, obviating the need for multiple levels of packaging. Whereas previously you had to package a war file and an EJB jar file inside a larger ear file, now a single war file will suffice.

We are also looking at WebBeans to bridge the gap between JSF and EJB technologies, making it possible to use EJB components inside the rich, contextual web application environment. Gavin King's blog has more details on what WebBeans adds to the platform in this respect. Don't forget to read all the comments!

Finally, the Bean Validation JSR offers a uniform validation API (with annotations, of course) that can be used in conjunction with JSF, JPA, JAX-RS, Connectors, etc.

Conclusion

We think you'll be pleased with the ease of development features you'll find in the Java EE 6 platform. Granted, making something as powerful as Java EE easy to use is an ongoing, titanic struggle, but we believe that by continuously delivering improvements on this front release after release we are succeeding in keeping the platform fresh for existing users and in making it more approachable to those who discover it at this time. It's never too late to enjoy developing software.

Related Topics >>

Comments

Question: So with release of EE5, then, what is the status of the JAXR API? I am using EE5 + NB 6.1. So how do I access JAXR? Thanks.

Ease of development is a good thing, but what kind of ease do the @GET and @POST annotations offer? To me, they don't offer anything, but only remove strong typing you get when extending the HttpServlet abstract class. It looks like this feature is taken from the Spring MVC @RequestMapping annotation, but the difference between the two is that while Spring MVC gives you enormous flexibility when defining your methods, the new Servlet annotations doesn't provide anything. Annotations have their use (like in EJB 3), but there is a difference between a Servlet and an enterprise bean. Why did the whole world suddenly step into the "annotation happiness" train? It may be me, but I often don't see any reason to step away from the normal Java constructs. I would suggest to the Servlet 3.0 EG to drop the GET and POST annotations and stick with the good old interfaces, like this: @Servlet("/mapping") class SomeServlet extends HttpServlet { doGet(...) doPost(...) } This way, you still have the possibility to do a classpath scan for @Servlet annotations, but not the burden of less strong typing.