J2EE 1.4 moves down the Enterprise ladder
Sun and the Java Community Process (JCP) members preparing the delayed Java 2 Enterprise Edition (J2EE) 1.4, scheduled for release this quarter, hope to reduce the number of APIs programmers must use when building applications and web services.
Solutions adopted include updating JavaServer Pages (JSPs) with version 2.0 and support for generic types used when building with the J2EE platform and Enterprise Java Beans (EJBs).
Santa Clara, California-based Sun and the JCP hope their changes will ensure J2EE becomes more accessible to developers who are not focussed on the enterprise and those who lack sophisticated programming skills currently required by the platform.
"We want to take the platform in the direction that makes it easier for [non enterprise] developers to use. The EJBs are a little bit easier to use," J2EE 1.4 platform product manager George Grigoryev told ComputerWire.
Java has long-been criticized as difficult to use. Vendors such as San Francisco, California-based Macromedia Inc have sought to remedy this by bringing their own easy-to-use development environments to the platform. San Jose, California-based BEA Systems Inc, meanwhile, launched WebLogic Workshop for Java web services that automatically glues together many of J2EE 1.3 and EJB 2.0 APIs used to build a web service.
"We want to reduce the amount of APIs that developers must use [with J2EE 1.4]," Sun distinguished engineer and J2EE lead architect Mark Hapner said.
Programming in JSP 2.0 will be simplified by adding the ability to use Simple Expression Language with the Tag Library. Simple Expression Language lets developers script logical expressions directly into JSP, rather than writing them in the Java language, making server pages a more effective scripting facility.
Generics, meanwhile, are types that contain data such as lists and are not defined to operate over a specific type of data. Instead, they operate over a homogeneous set, where the set type is defined at declaration. Generics provide flexibility of dynamic binding, compiler-detected errors are less expensive to repair than those detected at runtime, code review is simpler, and fewer casts are required making code cleaner.