Sun recently released the Java Platform Enterprise Edition 6 (Java EE 6) after its approval by the Java Community Process (JCP). However, Red Hat played a big part in taking the specification through to maturity.
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
The Java EE 6 specification, known as Java Specification Request 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,
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
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
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