Skip to main content

Raving about Java EE 5

Posted by kgh on February 21, 2006 at 9:52 AM PST


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

Related Topics >>