Graham Hamilton's Blog: February 2006 Archive

Java EE 5 went into Beta today. I've been raving at people inside of Sun about how important this is. I think Java EE 5 will be by far the biggest developer event of 2006. I love what we've accomplished in Tiger and Mustang, but Java EE 5 brings a much deeper and more important set of changes:

Java EE 5 is a major revamp of the Java enterprise developer programming model. It radically simplifies Java EE development, especially for Web Services (JAX-WS 2.0) and transactional components (EJB 3.0). And it also brings a new simplified database persistence model ("Java Persistence").
J2SE 5.0 (Tiger) was a big deal and a great release. But for me its most important feature was the Java language "annotations" work. That work was specifically intended to enable radical Ease-of-Development changes in Java EE. Now we're delivering those changes in Java EE 5 and it seems to be working: code that used to be convoluted and awkward in J2EE 1.4 is now dramatically simplified in Java EE 5.
It's all about making developers productive. We want to reduce the amount of time you need to spend worrying about the Java EE plumbing and thus increase the amount of time you can spend on your real application logic.

If you've been tracking J2EE, then you probably know that J2EE has pretty consistently conquered the high ground on functionality, stability, scalability, performance, flexibility, deployment, support and many other topics. So given all this abundance of riches, why do we need to do a major upgrade?

Well, in stepping back and surveying J2EE 1.4, we realized that the power, richness and flexibility had come with a significant price tag. You can do anything in J2EE, but doing common tasks can involve a lot of boilerplate and a lot of unnecessary concepts. We allow lots of options, which is good: but we often require you to specify lots of options for even simple cases, which is bad.

My very favorite ugliness (of which I am one of the prime perpetrators!) is the boilerplate for getting an EJB reference:

    Context initial = new InitialContext();
    Context myEnv = (Context)initial.lookup("java:comp/env");
    Object objref = myEnv.lookup("ejb/SimpleConverter");
    ConverterHome home = (ConverterHome) PortableRemoteObject.narrow(
                               objref, ConverterHome.class);
    Converter currencyConverter = home.create();

Yikes! What is all that code doing? Two casts and a PortableRemoteObject.narrow ?

So we realized that the big challenge was to greatly simplify the Java EE development model so that developers could use the power of Java EE, but avoid the complexity and the boilerplate. This was a key motivation behind a major Ease-of-Development initiative that we ran across J2SE 5.0 and Java EE 5.

For Java EE 5 we had some wide ranging goals:

Eliminate common boilerplate. If millions of developers need to type something, it had better be both useful and necessary.
Focus in on "Plain Old Java Objects" (POJOs). In particular, get rid of unnecessary interfaces and class hierarchy clutter.
Improve defaults, so that the 90% common cases "just work".
Eliminate the need for deployment descriptors. (But still allow people to add them later.)
Emphasize "truth-in-source-code" so that source code clearly specifies what is going on. For example, you shouldn't need to read an XML side file to understand what some code is doing.

All of this while still offering full binary and source compatibility. And while also still allowing people to use all the fancy bells and whistles when they need them. Including the full glories of deployment descriptors!

One of the key early decisions was to move to a more declarative programming model. Rather than requiring that people programmatically code up behavior, we wanted to allow people to specify behavior in some kind of declarative style, so that tools and libraries could recognize your intent and take care of the programmatic actions for you. But at the same time we wanted to ge away from complex XML side files or obscure naming patterns as the way of specifying behavior. We wanted to allow both simple declarative coding and also return to an emphasis on truth-in-source-code.

These various factor led to the decision to develop a new Java language feature annotations that would allow API designers to create targeted annotation types and then allow developers to easily use those annotation types to declaratively specify behavior, which will then be implemented by tools and libraries.

To illustrate this, let's look at how my earlier six lines of EJB reference code from J2EE 1.4 would appear in Java EE 5:

    @EJB Converter currencyConverter;

That's it. We are now using the @EJB annotation to declaratively specify that the field "currencyConverter" should be initialized to contain a reference to a Converter EJB, obtained from the default provider. When the Java EE container initializes our object it will use this information to fill in the field for us. Ha!

Annotations have been a big win. They are succeeding in allowing major simplifications of both the Web Services model (JAX-WS) and the core EJB model. To show that, let's start with a minimal Plain Old Java Object:

    public class Hello {
        public String sayHello(String param) {
            return “Hello “ + param;
        }
    }

Now let's turn it into a Web Service, by adding an @WebService annotation:

    import javax.jws.WebService;

    @WebService 
    public class Hello {
        public String sayHello(String param) {
            return “Hello “ + param;
        }
    }

Gee, that was easy. Now let's make it into an EJB. In this case we'll make it a stateless session bean by using the @Stateless annotation:

    import javax.jws.WebService;
    import javax.ejb.Stateless;

    @WebService
    @Stateless
    public class Hello {
        public String sayHello(String param) {
            return “Hello “ + param;
        }
    }

I love annotations. They change everything. Yes, as Java developers we do need to learn the new annotation lifestyle. When we read code we need to watch out for use of annotations and understand what that will mean. But the annotations are there in the source code, they are readable, and they sure simplify a lot of tasks.

As well as simplifying Web Service creation and EJBs, annotations also support the new and greatly simplified Java Persistence Model, which provides a lightweight Object-Relational Mapping for mapping between in-memory Java objects and on-disk database tables. (Java Persistence is being delivered as part of Java EE 5, but it will also be made available as an add-on for use with Java SE.)

There is a lot more in Java EE 5, including JSP 2.1, Servlets 2.5, JSF 1.2, JAXB 2.0, JAX-WS 2.0, StAX, and many smaller spec updates. There has been a lot of great work here, based on cooperation from many individuals across a wide range of companies working together through the JCP.

The official Java EE 5 Beta Bits are available at java.sun.com/javaee/5/downloads. However, bear in mind that the Reference Implementation for Java EE 5 is being developed in open source at the GlassFish Project and you can see the raw development and get the regular nightly builds there. And if you want, you can participate in building it!

For more on the Java EE 5 Beta, check out some of the other Java EE 5 blogs an The Aquarium.

2006 looks like being a good year for Java. Mustang looks like being a great update for Java SE - we went to Mustang Beta last week and we've already had a lot of positive responses from the Mustang early access snapshots. But Java EE 5 looks like it is on track to be the really Big Winner.

- Graham

Powered by
Movable Type 3.01D

java.net RSS Feeds