Sun Gives Early Peek at J2EE 1.5

At the Serverside Java Symposium, Sun execs say ease of development is the major theme of the Java 2 Enterprise Edition 1.5 as the company pushes to attract more developers.

LAS VEGAS—If Java 2 Enterprise Edition 1.4 was about bringing Web services into the enterprise Java fold, then J2EE 1.5 is all about ease of development in the enterprise Java space.

In a session at the Serverside Java Symposium here, Bill Shannon, a distinguished engineer at Sun Microsystems Inc., and Graham Hamilton, a vice president and fellow in the Java platform team at Sun, discussed the specifics of the next version of the J2EE platform and the ease-of-use features in the current version of the Java 2 Standard Edition (J2SE) platform—J2SE 1.5, also known by the code name "Tiger"—upon which J2EE 1.5 is based.

Giving one of the first public early peeks at the forthcoming specification, Shannon said the major theme of J2EE 1.5 is "ease of development. Were still in early planning, but its all about attracting more developers to it."

Sun, along with BEA Systems Inc., IBM and others, has been focusing on creating tools to address the complexity in building enterprise-class Java applications. However, the Java platform team at Sun is going further to include ease-of-development support in J2EE.

/zimages/3/28571.gifClick here to see how Steve Gillmor graded the Java players strategies.

While some observers note that most enterprises—as well as tool and application server vendors—have yet to implement J2EE 1.4, Sun and its partners involved in the effort are moving ahead to define the J2EE 1.5 specification. Indeed, Sun only a week ago sponsored a J2EE 1.4 kickoff event in San Francisco.

Shannon said some of the ease-of-development principles in J2EE 1.5 include the use of program annotations or mechanisms for associating metadata with program elements such as classes, methods and fields. Other ease-of-development features include the reliance on defaults wherever possible, and reducing the use of deployment descriptors, simplifying common scenarios, removing boilerplate code and adding utility classes, Shannon said.

In the future, Shannon said, rather than having to write a lot of code to handle mundane tasks, "we think we can get rid of all that, and well have a tool that can process annotations," he said.

The tool generates interfaces and deployment descriptors, while annotations use defaults that target common causes, Shannon said. Redundant interfaces also are removed. The benefits of this include fewer lines of code and fewer classes, simpler code, descriptors are eliminated in common cases, and it is easier for tools to deal with annotations than arbitrary code.

For instance, to simplify the development of a Java API for XML-based Remote Procedure Calls (JAX-RPC) service, "we can write just the implementation class, tag the class and let the annotation processing tool take over," Shannon said.

Shannon said deployment descriptors are great, but are an impediment to mass adoption, so the specification must allow for the use of both annotations and descriptors.

Shannon also said the Java Naming and Directory Interface (JNDI) is good for server implementers, but bad for developers. Instead, Shannon proposed a universal context as one place where users can look up things by type and name.

The J2EE 1.5 team has proposed container-initialized fields, according to Shannon.

Other improvements include support for the new JavaServer Faces toolkit; the Java Standard Tag Library; and JAX-RPC 2.0, which builds on Java Specification Request (JSR) 181, Shannon said.

Next page: J2SE 1.5 focuses on developer productivity.