The Benefits of Open Standards from The JCP

Overview

JCP & JSRs
JCP Governance
JCP Membership
JSR Implementations
Benefits
Drawbacks
Conclusion

JCP & JSRs

The Java Community Process (JCP) is an open standards body of member companies, Java User Groups (JUGs), and individuals that define standards based on Java technology. Each standard is organized under the banner of a Java Specification Request (JSR) and is composed of Spec Lead(s) and Expert Group (EG) members. Each JSR is responsible for developing a Specification Document (Spec), Application Programming Interface (API), Technology Compatibility Kit (TCK), and a Reference Implementation (RI). The RI is typically developed under an open source license.

JCP Governance

The JCP is governed by the Executive Committee (EC) which consists of companies like Oracle, IBM, and Red Hat Middleware. Elected JUGs include the London Java Community and SouJava. In addition, there are elected individuals like Werner Keil and Ivar Grimstad. All JSRs abide by specific JCP Procedures such as version 2.10.

JCP Membership

The JCP is open to everyone and has several different types of memberships including: Observer, Registered User, Associate Member, Partner Member, and Full Member. At the time of this writing there are over 1,000 registered members including approximately 70 JUG members.

JSR Implementations

It's not just Java SE that is governed by the JCP, but also Java EE, Java ME, and standalone technologies like the Portlet API and MVC. After a JSR EG defines and implements a standard, alternate implementations often times become available by open source organizations like the Apache Software Foundation and by vendors with competitive product offerings.

A good example is the case of Java EE, which is a collection of (mostly) server-side Java technologies. Open source offerings include WildFly, Payara, TomEE (Web Profile), and Resin (Web Profile). Commercial offerings include JBoss EAP, IBM WAS, and Oracle WebLogic.

Another example is Oracle (and the open source community) developing and maintaining the Mojarra RI for JSF, and the Apache Software Foundation developing and maintaining Apache MyFaces. What's more, over the years there have been diverse and competing component suite offerings from PrimeFaces, RichFaces, ICEfaces, Liferay Faces, BootsFaces, ButterFaces, MyFaces Tomahawk, MyFaces Trinidad, OpenFaces, HighFaces, TieFaces, MobileFaces, among others.

A third example is how the Portlet API has been implemented by Apache Pluto, Liferay Portal, IBM WebSphere Portal, Oracle WebCenter Portal, and JBoss GateIn Portal.

Benefits

While it might be difficult to quantify the value of JCP standards, I find that there are many benefits to participating in an open standards body like the JCP, and even more benefits to using Java standards developed by the JSR EGs.

Participating in Expert Groups

Over the years I've had the privilege of representing Liferay as an EG member on JSR 314 (JSF 2.0/2.1), JSR 329 (JSF Portlet Bridge Maintenance Release), JSR 344 (JSF 2.2), JSR 362 (Portlet 3.0), and JSR 372 (JSF 2.3). Most recently, I've been representing Liferay as the Spec Lead on JSR 378 (Portlet 3.0 Bridge for JSF 2.2). Each of these groups is run a little differently -- some have a weekly conference call, others don't. Some utilize the mailing list heavily, others rely more on an issue tracker.

I've benefitted tremendously from participating in JSR EGs, both personally and professionally. I've met lots of smart and interesting people and made some great friends along the way. I've learned to listen closely to the opinions of the various Spec Leads and EG members because they bring years (and sometimes decades) of industry experience to the table. This has especially been the case when I worked with Ed Burns (Spec Lead for JSF, representing Oracle), Michael Freedman (Spec Lead for JSR 329, representing Oracle) and Scott Nicklous (Spec Lead for Portlet 3.0, representing IBM).

Participating in Adopt-a-JSR

Another way to participate is through Adopt-a-JSR. This program enables a JUG to provide feedback to an EG. JUGs can also test development builds of the RI, help implement the RI, collaborate on issues, author tests in the TCK, etc.

Benefits to Using Java Standards

Longevity

The Java programming language has been with us since 1995. Java EE standards like the Servlet API have been with us since 1997, Portlets since 2003, and JSF since 2004. Each of these continue to mature and has received a recent technology update.

Popularity and Familiarity

According to the TIOBE Index, Java is once again the #1 programming language. It continues to receive feature updates in order to keep pace with popular programming trends (functional programming with Java 8 Lambdas is a recent example). According to a 2013 report from Oracle, there are over 9 million Java developers worldwide.

Backward Compatibility

EGs strive to maintain backward compatibility as much as possible. For example, web applications developed with the Servlet 2.x API should deploy within Servlet 3.x and 4.x containers without having to rebuild the Web Application ARchive (WAR). Portlets developed with the Portlet 1.x API should deploy within Portlet 2.x and 3.x containers. In order to achieve backward compatibility, one approach that EGs take is to @Deprecate obsolete APIs, but never remove them. Another approach to backward compatibility is to insulate developers from certain concerns. For example, JSR 329 portlet bridge implementations are required to execute the RENDER_RESPONSE phase of the JSF lifecycle in the RENDER_PHASE of the portlet lifecycle. But in order to ensure that JSF 2.x resources are automatically placed into the <head> section of the page, JSR 378 portlet bridge implementations are required to use the Portlet 3.0 HEADER_PHASE instead.

Based on Innovation

In general, rather than doing innovation within the EG, members work to standardize upon innovation that has taken place elsewhere. One example is JSR 299 (CDI 1.0), which likely incorporated ideas from a variety of Inversion of Control (IoC) containers including JBoss Seam, Spring, and Guice. Another example is JSF 2.0 which incorporated ideas from a4j and Facelets.

Community Support

Answers abound at StackOverflow for all kinds of questions about Java SE, Java ME, Java EE, and other Java technologies standardized by the JCP. For example, Bauke Scholtz (top 0.01% overall) and Arjan Tijms (top 0.82% overall) have answered a diverse myriad of Java EE questions, including the majority of questions concerning JSF. Adam Bien hosts the airhacks show on the first Monday of each month. Thorben Janssen regularly blogs at his Thoughts on Java site. New heroes are inducted into the Java Champions group every month. And loyal community leaders like Reza Rahman and the Java EE Guardians work steadfastly to protect and promote the reputation of enterprise Java.

Enterprise Support

It's not just financial/equity markets that crave certainty -- CTOs and project managers also need a measure of certainty for the technologies they adopt. They need to have a reasonable level of assurance that their technology choices will be supported in years to come. In order to satisfy this requirement, companies like Payara (GlassFish), TomiTribe (TomEE), Webtide (Jetty), Red Hat (EAP / WildFly), Oracle (WebLogic), and IBM (WebSphere) offer enterprise support.

Vendor Neutral

While it is true that each vendor makes their offering more competitive by offering vendor specific features, it is possible to guard against vendor lock by restricting application development to the standards-based APIs developed by the JCP.

Drawbacks

As with many areas of technology and processes, there are also drawbacks. JSR EGs can take well over a year to complete their work -- that might be too slow for organizations that do not take a long-term attitude towards technology adoption. For example, if an organization needs to adopt a Java technology for Reactive Programming, then waiting for the Java 9 Flow API might not be an option. In such cases the only choice is to adopt an innovative framework like Vert.x. Another drawback is waiting for vendors to implement one or more JSRs. For example, in the case of Java EE, organizations might have to wait up to two years for application server vendors to release a production-ready, certified product.

Conclusion

I have found that the benefits of participating-in and using open Java standards far outweigh the drawbacks. Thanks to the JCP, members have an opportunity to help Java technologies improve and remain relevant for years to come.

0 Comments

Please sign in to comment.

Menu Display

Blogs

Category Filter