eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Sun recently released the Java Platform Enterprise Edition 6 after its approval by the Java Community Process. However, Red Hat played a big part in taking the specification through to maturity.
The Java EE 6 specification, known as Java Specification Request 316 (JSR-316), includes support for two specifications where Red Hat played an important leadership role: JSR-299, which incorporates the JBoss Seam Framework for building Web 2.0 applications, and JSR-303, a data validation tool.
The adoption of both JSR-299 and JSR-303 provided an opportunity for Red Hat’s JBoss team to demonstrate its position of leadership in various areas within the JCP and to promote its objective-to simplify Java EE to make it more broadly appealing, allowing developers to benefit from a simple and standardized enterprise programming model. In general, the Red Hat objective is in line with the overall direction Sun and the JCP have taken for Java, which is for Java to reach a greater level of simplification and adoption.
Mark Little, Red Hat’s representative on the JCP Executive Committee and chief technologist for JBoss Enterprise Middleware, said: “With Java EE 5 we reduced the historical complexities associated with Enterprise Java Beans [EJBs] and persistence. Our work with Java EE 6 builds on that work to help Java reach a greater level of simplification and adoption.”
Little said Red Hat has held a seat on the JCP Executive Committee since 2003. And the company has several engineers leading expert groups for JSRs. Gavin King, the creator of JBoss Seam, led the expert group for JSR-299, and Emmanuel Bernard led JSR-303. And Little directly represented Red Hat on the Java EE 6 specification, he said.
“Starting with Java EE 5, we have been very active participants in the JCP standardization process, and have put considerable energy into improving the specifications to be easier to consume,” Little said. “We also deliver innovation beyond the standards in our various cutting-edge open-source frameworks.”
Little added that he believes the approval of Java EE 6, the latest iteration of the Java EE platform, is significant for both consumers of the technology and vendors that provide it.
“For consumers, it contains numerous improvements, notably the addition of JSR-299 and JSR-303 that greatly simplify EE application development,” Little said. “For vendors, it removes some of the restrictions that allow releasing products with more flexible combinations of EE standards.”
Moreover, “The introduction of a Web Profile is a significant gain, since not only does it lower the bar for entry-thereby allowing new innovation in the space-but it also allows vendors to ship a slimmer platform that is still EE compliant,” Little said “We have been early adopters of the Web Profiles concept through our JBoss Open Choice strategy. Web Profiles will give customers a tailor-made fit for the deployment needs-from simple Web applications, to light and rich Java applications, to Java Enterprise Edition [EE]-based applications.”
In addition, Little said JSR-299 and JSR-303 greatly simplify Java EE application development by bridging the various Java EE component models into a more unified approach.
“More specifically, JSR-299 defines a set of common services that can be applied to any Java EE component,” Little said. “These include context/state oriented lifecycle management, type-safe dependency injection, event handling, and a powerful SPI that allows for portable extensions.”
Meanwhile, “JSR-303 unifies validation logic for any Java object, but is most directly applicable to those which represent the data model of the application,” Little said. “Using JSR-303, a developer can express the validation rules as Java annotations in one easy-to-maintain place, the model object itself. Java EE services such as JSF [JavaServer Faces] 2 and JPA [Java Persistence API] 2 execute these rules automatically, thereby eliminating the need for a duplicate developer-provided validation code as commonly seen today.”
The JCP approved JSR-316 at the end of November, with Google, Sun, Red Hat, IBM, HP, Oracle, SAP, Ericsson AB, the Eclipse Foundation and Fujitsu voting for the specification. SpringSource and Intel abstained from the vote, and the Apache Software Foundation voted against it.
In a comment about its vote, IBM said:
“With the exception of the JSR-330 [Dependency Injection for Java] and JSR-299 injection support defined by the EE 6 platform, we believe that this new specification brings value to the industry. We remain concerned that the injection support defined by the platform will create unnecessary difficulties for the community. IBM will continue to support both expert groups in the development of a single integrated and extensible injection programming model.
“IBM’s vote is based on the technical merits of this JSR and is not a vote on the licensing terms. IBM supports licensing models that create an open and level playing field by allowing third parties to create independent implementations of Java Specifications and that do not allow individuals or companies to exercise unnecessary control for proprietary advantage. We support open source as a licensing model for contributions in the JCP, and would hope others will support this direction. This comment is not necessarily directed at the current business or license terms for this JSR; however, it is a statement of IBM’s preferred licensing model.”
Responding to eWEEK about the situation, Little said: “While we can’t speak for IBM. If you read IBM’s note on both JSR-330 and JSR-299, you can see that their issue wasn’t with the 299 spec itself, but was instead concerned with potential compatibility problems that could arise as a result of JSR-330 only standardizing annotations. In other words, a developer using JSR-330 but not JSR-299 needs to use some proprietary mechanism for a portion of their application, and if they eventually migrated to JSR-299 or another JSR-330 provider, they would be required to port that portion of the application.”
However, “We do not share this concern because we feel that if a developer wants a portable application they will use JSR-299 from the start,” Little said. “If the developer chooses to use JSR-330 support provided by a proprietary framework, then they would knowingly be developing code against that framework, and thus realize the potential drawbacks.”
Meanwhile, Apache’s issue with the Java EE specification is not related to the technical merits of the JSR, but ASF “voted No with the following comment: The Apache Software Foundation’s vote is based on the point of view that this spec lead-Sun-is in violation of the JSPA [Java Specification Participation Agreement]-http://www.apache.org/jcp/sunopenletter.html-and therefore shouldn’t be allowed to lead other JSRs until the above matter is resolved.”