Graham Hamilton's Blog

Raving about Java EE 5

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.

Comments

• Yes, Java EE slightly simplifies the old way of doing things. However you too fell into the trap that Spring fell into:
  Assuming that less code == simple

  I did lots of consulting and lecturing regarding J2EE and I find that the additional code is pretty easy to understand. The main problem most people had with J2EE wasn't the code (XDoclet, WSAD etc... hide most of the code) it was the integration, deployment and missing features.

  
  Its really easy to write a simple J2EE application, however its not as simple to package and deploy it especially when something goes wrong. J2EE servers fail in the most horrible way (same is true for Spring and most other servers) giving you an internal error message that doesn't help. Writing something "real" and "useful" in J2EE is also difficult sometimes with all the cumbersome rules.

  
  Sun typically says that these issues are not "spec issues" but "implementation issues"... This is a cop out! The spec can define anything it needs:

  
  The spec can define a decent validation sequence and appropriate error messages for validation. The Java SE spec defines validation and so does the XML spec. However, since Java EE is far more complex than plain Java SE it should define a far more elaborate validation scheme that will break many existing applications. This can be solved by enabling this feature only for newer applications, applications will move to this spec to increase portability and standard compliance. Yes there are tools to validate J2EE applications, they crash and burn on every single real world application I saw and none of them are a standard part of deployment!
  The spec should close the gaps and black holes within it. There are several areas where the spec just allows the application server to choose a propriatery way to implement functionality such as authentication or defining transaction isolation. Yes yes I know that every vendor implements this differently, thats why we have an abstraction... Find a lower common denominator and go with it and if all else fails force by vote some of the guys to align with the rest! There is no excuse for not being able to define something as trivial as these two things in a standard way! Default login modules and behaviour (such as logoff) should be standard, so should isolation.

  
  Yes I will be upgrading to Java EE 5.0 and happily so, it is a fine improvment but it doesn't simplify the important things it just plays followup to Spring which IMO didn't solve the problem either just added more abstractions to grep.

  Posted by: vprise on February 22, 2006 at 05:16 AM

• 
  This is certainly a good commentary, though I wouldn't down play the easy of coding improvement quite so much. Deployment is indeed the big issue, but I also believe it has already been solved with the Java Studio Creator 2.0 IDE.

  Granted, trying to deploy a JSC 2.0 project to anything other than the Sun Appserver is a nightmare. I have tried, I have Web Logic 8.1 loaded, Tomcat, and IBMs Webspherese.

  The key point here is that everything deploys perfectly, and easily, to the Sun Appserver, so why use anything else ? No one is going to catch up to the power delivered by JSC 2.0 in the next couple years, including IBM and Microsoft.

  So, I am throwing my support behind the Sun Appserver, and starting a new project to build one thing that I have not found in any Appserver, and that is an API to do things like query and load resources from Java code, deploy and undeploy apps, etc. This shouldn't be to hard to do, I just need to wrap the functions normally called from the Asadmin command line.

  
  

  Posted by: joepaladin on February 22, 2006 at 11:43 AM

• Re: ..that is an API to do things like query and load resources from Java code, deploy and undeploy apps, etc.

  I think this is supported. Please take a look at AMX page of project GlassFish. The following documentation also describes this with few examples.

  Posted by: ai109478 on February 22, 2006 at 07:11 PM

• I didn't mention a need for an API to deploy/undeploy. I mentioned a need for the specification to define the procedure of what to do when deployment goes wrong.
  The Sun One application server with Java Studio Creator makes deployment "simple" for the simple stuff. However, the problem doesn't exist when everything works. What happens if I messed up my XML or my annotations? What type of error do I get when I use the API incorrectly?
  Good examples would be:

  Defining object mapping that does not match the DB schema.

  Invoking an API while the application server is in an initialization state and can't process the API correctly.

  Reference to an object that doesn't exist.

  Duplicate versions of classes (this happened to me because Netbeans makes it so damn easy to include libraries and pulls them into the WAR file by default took me a whole day to figure out the damn error messages).

  The last example really hurt me personally and its just one of many examples where I worked hard to understand what the server wants. I don't need a GUI, I don't need 2 click deploy. User friendly is more than a flashy shiny GUI, its a state of mind that people at Sun just can't grasp (due to over the top hacker mentality I'm all to familiar of at Sun)... Its a culture thing, make everything simple to begin with and when something fails try to understand why and give the right excuse, don't just dump the internal state of the application server on unsuspecting victims. Design with the intent of failing gracefully.
  

  Posted by: vprise on February 23, 2006 at 07:21 AM

• and starting a new project to build one thing that I have not found in any Appserver, and that is an API to do things like query and load resources from Java code, deploy and undeploy apps, etc.

  That sounds a lot like Cargo:, not to mention JSRs 77 and 88...
  

  Posted by: felipeal on February 24, 2006 at 04:31 AM

• Hi "vprise",

  I was actually responding to "joepaladin". You make good points also. A group of us are looking at the user experience of the application server. We are very interested to hear more from you. Please contact us at users@glassfish.dev.java.net.

  You may also use the GlassFish Issue Tracker to request feature improvements. If you like Sony Play Station Portable (PSP), please share your experience with the Application Server here!

  BTW: Application Server provides a verifier (/bin/verifier --help) that you may use to find issues in your archive. You may enable the verifier during deployment of your application too. Use the "asadmin deploy --verify=true" option in CLI or the "Verifier" checkbox in admin console. By default, verifier is not turned ON since it is an expensive operation. We are discussing if we should run a sub-set of the tests always. Please check out the tech tips and examples at Project GlassFish. This blog talks about trouble shooting annotation issues during deployment. Please refer to this blog for on-demand initialization of application server services. During the Java EE 5 time frame, we worked on the application server class loaders. An early draft of the documentation is available here. We are working on examples and use cases for this doc so that user can solve the classloader issues quickly.

  Thanks for the great feedback.
  

  Posted by: ai109478 on February 25, 2006 at 01:44 PM

This work is licensed under a Creative Commons License.