o develop even a simple J2EE application, developers must write lots of boilerplate code (as Enterprise JavaBeans, or EJB, in Java) and set up a myriad configuration files (as deployment descriptors in XML). Therefore, to become a J2EE developer, a programmer must be familiar with EJB and XML. For novices, these can represent a daunting learning curve.

Adding to its reputation of complexity, the current J2EE specification (1.4) was written a long while back using JDK 1.2, so it does not include the rich, ease-of-use features offered by later JDK versions, such as J2SE 5.0’s generics and annotations support.

One of the main goals of the upcoming Java EE 5.0 release is to keep the power of J2EE, while making common development tasks simpler. To accomplish this, Java EE 5.0 aims to provide better default behavior and configuration by allowing most containers to get what they want from the application without using deployment descriptors. Java EE 5.0 puts annotations to great use for this purpose. Although developers don’t need to know the implementation details (the containers do the bulk of the implementation work), these new features will make enterprise Java applications lighter and faster.

This article explores the new features J2EE developers can expect in Java EE 5.0. It takes a brief look at annotations first before delving into the others.

[Author Note: In case you haven’t heard yet, the latest version of J2EE is called Java EE 5.0. Henceforth, new versions will be referred to as Java EE and J2EE will refer to earlier versions.]

Java Annotations

An annotation is a special kind of modifier that you can use anywhere you use other modifiers (such as public, static, or final). By convention, annotations precede other modifiers. They consist of an at sign (@) followed by an annotation type and a parenthesized list of element-value pairs. The values must be compile-time constants. In other words, Java itself provides a specific list of annotations.

Annotations do not directly affect program semantics, but they do affect the way tools and libraries treat programs, which can in turn affect the semantics of the running program. Annotations can be read from source files, class files, or reflectively at run time. Separating the definition from the enforcement and providing a way to introspect these constraints provides much more flexibility in the enforcement.

Most Java developers already are familiar with annotations. For example, all JavaDoc tags and transient tags are examples of annotations.

Injection of EJB Entries

With the current J2EE architecture, in order to expose any business method, you need to provide EJB wrappers for the home and remote interfaces. But with Java EE 5.0, you can annotate any field or method of an application component with the EJB annotation. The annotation itself represents a reference to an EJB session bean. The reference may be to a local or remote home interface of the session bean, or it may be to the business interface of an EJB3 bean.

For example, the following code uses annotations to make a PurchaseOrder class into an EJB:

@EJB private PurchaseOrder po;@EJB(	name = "ejb/myEnterpriseApp",    	beanName = "po1",	beanInterface ="PurchaseOrder.class",	description =" The Purchase Order for my enterprise application")private PurchaseOrder po;

The enterprise bean will have the JNDI look up the name java:comp/env/ejb/po. As the target of the name is not specified anywhere, the container must resolve the target.

Cool, huh?! Now you can make any of your existing applications into a Java EE application just by injecting the EJB annotations into your existing business methods and deploying them in a Java EE 5.0-compliant container.

In cases of conflict when a deployment descriptor is provided along with annotations, the container ignores the annotations and uses the deployment descriptor entry. This feature allows current J2EE applications to be migrated “as-is” to Java EE 5.0-compliant containers.

Enhanced Deployment Descriptors: Injecting Environment Entries

Along with the tag in deployment descriptors, Java EE 5.0 provides a new tag to make business fields accessible from the application component’s code: . Alternatively, you can use the @Resource annotation tag for the same purpose.

For example, the following code uses an annotation to limit the number of items in a purchase order to 10:

// can be configured from the deployer@Resource int numberOfItems;public void validatePO(PurchaseOrder po) throws NumberOfItemsException{ if(po.getItemCount() > numberOfItems)	throw new NumberOfItemsException("My PO cannot have more than 10 items");}

The following code uses a deployment descriptor for the same purpose:

	 Number of Items in my PO 	 numberOfItems 	java.lang.Integer	10Looking up this value:Context initContext = new InitialContext();Context myEnv = (Context) initContext.lookup("java:comp/env");Integer NumOfItems = (Integer) myEnv.lookup("numberOfItems");

When environment entries are injected into the code using either annotations or the tag, it is the container’s responsibility to provide the lookup for these values.

New CMP Tags

Java EE 5.0 provides many new tags for container-managed persistence (CMP). Developers just specify the table name and column names as annotations, and the container does the rest.

For example, in the following code snippet, @Table specifies that the Account class data will be stored in the ACCOUNT table:

@Entity@Table(name = "ACCOUNT")public class Account  implements java.io.Serializable {@Id   public String getUserId() {      return userId;    }@Embedded   public ContactDetails getContactDetails() {        return info;    }@Column(name="FIRSTNAME")   public String getGivenName(){        return givenName;    }}

A developer can use the @Column tag to map business field names to more appropriate table column names.

Web Services in Java EE Container

The principal goal of Java EE 5.0 is to provide a simplified model for Web services development that is easy to learn and quick to develop. To that end, it provides the Web services infrastructure developers require for building robust, maintainable, and highly interoperable integration applications.

Java EE 5.0 will provide Web Services Metadata as an easy-to-use syntax for describing Web services at the source-code level for the Java EE platform. The syntax will be amenable to manipulation by tools. For example, the following code implements a Web service:

@WebService(name="MyPOIntf", targetNamespace = "urn:MyPurchaseOrderService")@SOAPBinding(style = SOAPBinding.Style.RPC)public interface MyPOIntf extends Remote {   @WebMethod   @WebResult(name="result")    public String submitPODetails(String poXmlString)throws  RemoteException;}

First, an interface is defined for the end points with WebService annotations. Then any class can implement the functionality for the Web service by implementing this interface.

While Web services still remain a mystery to many seasoned Java developers, Java EE 5.0 will enable them to easily develop and deploy their existing enterprise business applications into Web services applications without much hassle. So even though J2EE’s complexity guarantees my paycheck for some years to come, six months to a year from now (Java EE 5.0 originally was scheduled for release by the second half of 2005, but due to JCP approval delays, it has been postponed to Q1 of 2006.), I imagine the IT market will be flooded with Java EE Web services developers.