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
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.

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) {
Related Topics >>