The latest expert opinions, articles, and guides for the Java professional.
Who makes Java? (hint: it’s a community thing)
Java is important, so a lot of individuals both inside and outside various organizations and huge corporations oversee the evolution of Java and participate in its future. Some of the more well-known members include Oracle, IBM, Red Hat, Eclipse Foundation, the London Java Community (LJC), SouJava, Cloudbees, Goldman Sachs, Credit Suisse, Fujitsu, Intel, Nokia and Twitter.
Let the acronym parade begin!
Java technology evolves through a continual process of improvement, made possible by the work of the Java community. The JCP is the official organization for making your improvements to the platform, and this is largely possible through Membership to the JCP. Public observer participants have access to the work of the JCP and can provide suggestions and review materials, as a result of the JCP.Next effort. JCP Members can serve on a JSR expert group, contribute ideas, and lead JSRs. Membership in the JCP offers you a chance to become a permanent part of the Java platform’s history by contributing your work and recommendations to the various standard specifications.
– Anonymous Expert
THE JAVA COMMUNITY PROCESS (JCP)
The Java Community Process (JCP) is the process through which the future of Java specifications are crafted. This has been the case since December 8th 1998 when Sun Microsystems introduced this mechanism to the community. The idea of the process is to capture the community ideas and gain their involvement in the evolution of Java. Suddenly, engineers all over the world could begin getting involved in the language they use professionally! If you think the process is simple however, you’d be wrong! Consider the process like a pipeline, where in one end goes an idea, a proposal, if you will, called a Java Specification Request (JSR) and on the other end comes out a feature in the next release of Java. But in between all that, we have a JCP EC voting, then JSRs with an EG that produces TCKs and RIs and a PMO. What?
JCP EXECUTIVE COMMITTEE (EC)
This JCP Executive Committee (EC) comprises of some of the major players in the Java industry, such as Oracle (permanent seat), IBM, Red Hat and many more. But also, there are community seats which are owned by the London Java Community, SouJava and MoroccoJUG. It’s important to stress that the community seats hold just as much power as the big cheese corporations. You can’t just join the group though, you must be elected into the group. The last election, at the time of writing, was on November 2013 and those now serving on the EC are fulfilling either a one or two year term.
To see a full list of those who are currently serving on the Executive committee, you can check out the committee members here. Elections are voted on by JCP members. Hang on, JCP members? We’ve not talked about them yet, let’s check out what they’re all about.
HOW TO BECOME A JCP MEMBER
Anyone can be a JCP member. You can, we can, heck, even Chuck Norris could if he wanted! A JCP member might be an individual, a company or an organisation. Either way, they all get a vote at election time, so you should sign up here and make your vote count. Even in geek terms, it’s not the coolest club to be involved with necessarily but it is important if you care about the future direction of the Java Platform. And if you do, then you’ll see why JSRs are so important.
A JSR? WHAT’S THAT?
A Java Specification Request (JSR), which describes the development of a new specification on Java SE, EE or ME. A JSR can also describe a significant change to an existing specification on the Java Platform. In it’s time, since 1998, over 300 JSRs have gone through the JCP process—Now that’s a lot of coffee. Here are some example JSRs whose resultant implementations you’re more than likely using. Plus the great thing is, if you don’t like the way a specification was put together, you can trace back who was responsible and give them the required expletives that up till now your poor dog has had to soak up. (Note: this is the first step to you contributing to a future JSR and killing those expletives before they were even conceived)
Here are a few JSRs which many of you have most likely used or heard of.
- JSR 1 – Real time Specification of Java
- JSR 19 – Enterprise JavaBeans v2.0 — ARRRRGGGGHHHHHHHH!
- JSR 127 – JavaServer Faces (First release of JSF)
- JSR 294 – Improved Modularity in the Java Programming Language (AKA – Project Jigsaw)
- JSR 335 – Lambda Expressions for the Java Programming Language
- JSR 337 – Java SE 8 Release Contents (Umbrella JSR)
WHEN A JSR GETS AN EXPERT GROUP (EG)
Once a JSR has been thought up, an expert group (EG) forms, comprising interested parties from JCP EC and JCP members and voted over by all. Typically, the quality of a JSR will be determined by the strength of the Expert Group. Creating a diverse group will at this stage seed a JSR with the necessary viewpoints and expertise for the JSR to have a higher chance of being accurate and successful for the future needs of the Java community. An expert group doesn’t just magically appear out of thin air though, it requires an Expert Group leader or a Spec Lead. Now if you wanted a geek leader card, here’s a great one to have. Sound like herding cats? At times, it probably is!
JSR EG MAKES AN RI & TCK FOR THE PMO (WAT?)
The role of the expert group is to grab the JSR by its horns and start discussing things in groups and distribution lists for that JSR which the EG organises. Slowly the specification begins to evolve, ultimately resulting in an number of APIs of some variety, a reference implementation (RI) for the JSR and a Technology Compatibility Kit (TCK). The JCP is overseen by the Program Management Office (PMO), which is a part of Oracle.
For a specification to be finalised, there are a couple of hard deliverables that need to be created as we’ve mentioned, and these are the reference implementation and a TCK. Remember, people are going to be implementing these specifications and while the written word can be ambiguous a reference implementation or test suite is less so (most of the time). Although it relies on these both being cared for and loved just as much as the specification.
REFERENCE IMPLEMENTATIONS (RIs)
A reference implementation is developed by the expert group and can be used by others wanting to implement their own version as a reference… errr… implementation. Now this TLA was very well named! The RI must pass all tests in the TCK. There’s not much else to say about RIs to be honest! Examples of RIs in the EE and SE space include Glassfish for the Java EE 7 umbrella JSR – JSR 342, and the OpenJDK for the Java 8 umbrella JSR – JSR 337.
TECHNOLOGY COMPATIBILITY KIT (TCK)
Why is a TCK so important? Well, once our toddler draft specification becomes a teenager final draft and then voted into an adult JSR where it’s released into the real world, it needs to first pass the TCK test suites that are run across the implementation. If all tests pass, then so do you.
All our interoperability is based on how complete the TCK is, so ideally, the TCK should be open, easily licensed and contributed to by users, right? Well actually, no, this bit is still behind closed doors and has actually caused huge amounts of problems around the Java space, including the shenanigans around the Apache Harmony project–the JVM implementation we mentioned earlier.
Quick story: On November 16, 2011, the Harmony project was officially retired from the Apache Software Foundation (ASF), because of their inability to get a TCK with acceptable licensing. Apache wrote an open letter outlining the problems that existed with the existing licensing, which meant progress could not be made. Oracle replied on their company blog, pretty much saying, while they plan to get to it, it’s not a priority for them. This was a blow to the ASF and led to Harmony being retired as well as Apache leaving the JCP EC. This was an unfortunate thing, since the ASF has brought many valued and important solutions to the JCP and software industry in general, from Tomcat to Camel and more.
If this all seems pretty complicated, you’re not wrong. As necessary as it is complicated, how can the JCP compete with more nimble proprietary implementations that can be made available so much faster than the average JSR implementation? In the next part, we see how the stages of the process actually look.
I will admit that developing standards in a collaborative manner is always going to take longer than a single organization or a small group developing a proprietary implementation. That’s not necessarily a bad thing; when I get on a plane I want to be sure that the interface between the wings and the fuselage has been very carefully designed and tested! Once you define a standard, you’re stuck with it. (We don’t make incompatible changes from release to release that’s not how the standards world works.) This means that you need to take the time to make sure you get things right.
Over the years the Java platforms have incorporated many ideas that were first developed out “in the world”. That’s a good thing. But standards organizations are not the best place to innovate; that should happen elsewhere ideally in an open source community where ideas can be tried out, tested, and evolved in an agile manner. When new ideas have proved themselves, and when we have some real world experience with them (ideally with more than one implementation) then it may be time to standardize them. This is the model that the JCP is moving towards, and it seems to work well.
– Anonymous Expert
Leave a comment