Java: A platform for platforms
Sun's reorg may seem promising to shareholders but it's also a scramble for position. The question now is whether Sun can, or wants to, maintain its hold on Java technology. Especially with enterprise leaders like SpringSource and RedHat investing heavily in Java's future as a platform for platforms

Also see:

Discuss: Java: A platform for platforms?

Featured Whitepapers
Newsletter sign-up
View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java
Email Address:

Simplify enterprise Java development with EJB 3.0, Part 1

Use annotations to develop POJO services

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone

Java Enterprise Edition, or Java EE (previously called J2EE), is a powerful but notoriously complex platform for developing server-side applications. Since its early days, complexity has long been cited as one of the major factors holding back Java EE's adoption. In a previous JavaWorld article "On the Road to Simplicity," I discussed some of those issues that complicate Java EE application development, specifically those related to the current Enterprise JavaBeans (EJB) 2.1 specification.

Over the past three years, the Java open source community, the Java Community Process (JCP), and major Java EE vendors have endeavored to make Java EE simpler. For example, new design paradigms, such as POJO (plain-old Java object) services, service interceptors, and dependency injection, are practiced in real-world applications to simplify Java EE development. And new tools and frameworks, such as Hibernate, AOP (aspect-oriented programming), Struts, XDoclet, and Spring, have been widely adopted for the same purpose.

Simplification is not feature reduction
Simplifying a programming model does not reduce its functionality. Simplification merely hides the complex logic behind framework code or reusable components. In essence, it shifts complexity from one part of the system that needs explicit management by application developers to another part invisible to most developers.


Those patterns and tools have made life easier for beginning developers while improving the productivity for experienced Java developers and are currently being incorporated into the next generation of Java EE standards (i.e., EJB 3.0) by the JCP. A recent study by Java developer Raghu Kodali has shown that porting Sun's Java EE tutorial application RosterApp from EJB 2.1 to EJB 3.0 resulted in more than a 50-percent reduction in code.

Java annotations are the key behind EJB 3.0, which ties POJO services, POJO persistence, and dependency injection altogether into a complete enterprise middleware solution. In this article, I use a sample application, the JBoss EJB 3.0 TrailBlazer, to illustrate how to develop lightweight EJB 3.0 POJO applications with annotations. The TrailBlazer application implements an investment calculator multiple times using different tools and APIs available in EJB 3.0. The sample application runs out of the box in JBoss Application Server 4.0.3 and is fully compliant to the latest EJB 3.0 specification (public review) at the time of this writing.

Let's begin by examining the benefits of an annotation-driven programming model.

EJB 3.0's annotation-driven programming model

From the developer's point of view, EJB 3.0 extensively uses Java annotations. Annotations have two key advantages: they replace excessive XML-based configuration files and eliminate the need for the rigid component models.

Annotations versus XML

XML-based deployment descriptors and annotations can both be used to configure service-related attributes in Java EE applications. The two differ in that XML files are processed separately from the code, often at runtime, while annotations are compiled with the code and checked by the compiler. That has some important implications for developers, as I list below:

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone
Comments (1)
Login
Forgot your account info?

@PostConstruct or @InitBy Anonymous on October 31, 2008, 11:15 amTo this article, if having any, @PostConstruct is invoked after @Init. However, it is stated the other way around in Java EE 5 Tutorial from Sun's site. ???

Reply | Read entire comment

View all comments

Add comment
Anonymous comments subject to approval. Register here for member benefits.
Have a JavaWorld account? Log in here. Register now for a free account.
Resources