About the authors
Ben Evans is the LJC’s representative on the Java SE/EE Executive Committee. Martijn Verburg is one of the co-leaders of the London Java Community (LJC).
Introduction
Earlier this month, the LJC, aka the London Java User Group (JUG) became the first JUG to be elected to an open seat on the Java Standard Edition/Enterprise Edition Executive Committee (Java SE/EE EC in short). In this post, we’ll explain what the forthcoming changes to the Java Community Process (JCP) mean and how the LJC intends to help with the process of reform at the SE/EE Committee level.
What is the JCP? What is a JSR? What is the Executive Committee?
The JCP is the process by which new versions of Java and standardized Java technologies are produced. The process involves the use of a standardized set of documents which define the new technology. These are referred to as Java Specification Requests (JSRs). A JSR must also include:
- A Reference Implementation (RI)
- A Testing Compatibility Kit (TCK)
JSRs are usually referred to by their number – so for example the effort to define generics (which ultimately made its way into Java 5) was JSR 14, and the Java Persistence API (JPA) v2.0 was JSR 317. There are even JSRs for the new versions of Java itself! For example, JSR 336 defines what will be in Java SE 7.
The body which is responsible for deciding which JSRs can become official Java standards is the Executive Committee, which is made up of a number of corporations, exceptional individuals and interested parties – including ourselves, Oracle, IBM, Fujitsu, Google, Red Hat and others.
We’ll be putting up a post in the very near future which explains how our participation in the EC will work – but we want to hear your views about the issues facing the community – so we can do the best job of representing you that we can.
Every JSR goes through the same lifecycle, as shown in the diagram.
How to become a JCP member
You can become a JCP individual member very easily and you can also join as part of a corporate, academic, non-profit or JUG organisation (LJC members, please sign up!). This is the first step you should take to get involved. It’s actually very easy to join, see the JCP home page for instructions – http://jcp.org/en/home/index
It’s not as easy to get involved in a JSR as we’d like
Currently it can be quite difficult to get involved in some of the JSRs. Under existing rules, parts or even all of a JSR can effectively be run in private, making it impossible for outsiders to join. Most JSRs run at least partly in the open, but several don’t.
There is also a tendency to come up with a TCK and RI quite late in the process, which doesn’t allow the wider community to actually ‘play’ with the proposed JSR and give meaningful feedback.
Some JSRs are simply just deeply technical and only real experts can get involved early on, but that’s just the nature of the beast of something like JSR-292 (the new invokedynamic bytecode for the JVM).
But you should still jump on in
That said there are several JSRs which are run in the open and do solicit feedback with early RI’s and TCKs. Please visit the JCP home page and browse through the JSRs on the left hand menu. Each JSR page will list their public mailing lists, issue trackers etc. Simply join the mailing list, say hello and ask how you can help out (even though you’re not necessarily a domain expert).
JSR-107 (Caching) is an example of a recently revived JSR that’s running out in the open and is happy to receive help (big and small) from Java enthusiasts.
In the coming weeks, we’ll be explaining which JSRs are currently active – so people could participate in right now. We’re also about to see the work for JDK 8 kick off in earnest. This is a really great time to start thinking about how you could get involved.
If you have questions, or want to know more – please comment here, or start a thread on the LJC mailing list. We really want to help and encourage as many people to get involved as possible – and there’s lots of help available.
Things are about to get better!
This is a massive time of change in the Java ecosystem and during times of change you have the best chance to positively influence the outcome.
Oracle is working very hard to make the JCP and JSRs more open. Despite much anti-Oracle publicity, they really are trying hard (see JSR 348 comments below). Sure, there’s still plenty of areas that we’d like to see the process work differently (and we’ll be advocating for those), but our experience so far has been very positive and we think there’s real potential for some very constructive change.
For the first time, two JUGs are on the EC (us & SouJava – The Brazilian JUG). This means that the world wide developer community (9-10 million) has direct representation for the first time
JSR 348 has just been announced which is going to take great strides to open up the JCP, the Expert Groups (EGs) and just the overall ecosystem of standards. We implore you to get involved and send in feedback, whether its to us, your local JUG leader or through hte official JCP channels (see the contact us on at jcp.org)
The LJC and many other EC and EG members are very firmly in the camp of making JSRs more accessible to everyone. As well as enforcing openness via JSR 348, we also see a very real chance to have each JSR really engage with the community. We’re going to try and work with JSR EGs to see how we can raise their profile, make them really easy to access etc. Something along the lines of running a successful open source project is what we’re looking at.
Phew, long post. But there’s a reason for that, we’re really excited about the future! 🙂
Cheers,
Ben (@kittylyst) & Martijn (@karianna)
7 comments
Comments feed for this article
June 1, 2011 at 5:18 pm
Reza Rahman
Good work guys – keep it up!
June 1, 2011 at 10:05 pm
javajoe
I would hope that every single Java 8 JSR is run under the new forth coming rules. If not, we will see another 3 year cycle of what we currently have. While Oracle claims great community participation with JSR’s like project coin you only have to visit the mailing list to find out how this is far from the truth. People are still waiting for the “private mailing lists” [1] to be published so they can provide feedback. But in light of Java SE 7 shipping real soon what really could be done with community feedback? Why were such deliberations conducted in private? Why claim this huge community success story when there was none (even on the selection of
these language changes!!)? The lamba JSR for Java 8 is no different. They have made some progress and some major decisions but there is not even an expert group yet! Even JavaFx 2.0 which will be released in Q3 has made decisions on how they know/perceive lambda will be designed (use of single abstract classes) . What happens if the expert group decides that single abstract class is not the way to go? Maybe they decide that function types are a much better design decision. The problem here is that the community is being left out .. what Oracle seems to want is people to doing the QA.
This is were I hope the JUGS can make a difference.
[1] http://mail.openjdk.java.net/pipermail/coin-dev/2011-May/003269.html
June 2, 2011 at 3:25 pm
Werner Keil
There’s an EG for the Lambda JSR, but most of the SE JSRs unfortunately lack the transparency you can see practiced in other areas like many good EE examples (JSF, JPA and those lead by Red Hat)
Being the only Individual Member on SE/EE I am the 3rd representative of the community beside the two JUGs. All providing a wider set of ideas and thoughts beyond the narrow borders of Silicon Valley or at least United States, where most other (SE/EE) EC members are based.
June 2, 2011 at 5:55 pm
karianna01
Hi Werner Keil, apologies for the oversight in not mentioning you as the 3rd community representative. That was remiss of us. Look forward to working with you on more open reform!
June 3, 2011 at 5:13 pm
Sean Sheedy
Thank you for posting this. The JCP ECs need strong, vocal members who are in touch with the developer community, to represent its needs and provide balance and perspective to corporate interests.
JSR 348 is only the first of two JSRs addressing governance changes. It was decided early on (before you joined) in the Working Group/EC to divide the work into two JSRs. This was so that reforms that could be agreed up would not be held up by debate and possible stalemate over more contentious changes.
This means that 348 is unlikely to address the issues that led to the departures of Doug Lea, Tim Peierls, and Apache. It doesn’t mean 348 is watered down; in Seoul we spoke about completing this JSR aggressively to put much needed election reforms and other reforms in place before the next JCP election takes place.
It does mean that the more difficult issues could be sufficiently contentious that the second JSR might never complete. This is where your informed judgement of what would best serve individual developers is going to be very important.
You enter an EC where key EC members who felt very strongly that Java standards should be unencumbered have recently departed, leaving a lack of representation of that perspective. It is currently an EC where most of the corporations that supported this stance have somehow been placated and are no longer raising this issue.
The question becomes, where will you stand when these issues resurface during the second JSR. Oracle’s position here is clear and it appears that the majority (but not all) of the current EC seems willing to accept it. How this might play out in today’s EC would make this comment far longer than it already is.
So, in a way it is a good thing that the first JSR (348) will be an “easy” JSR. It’s going to be short enough to not delay discussion of the difficult issues too much longer, and long enough to allow time for understanding the dynamics behind these issues that being on the EC will help provide. That you’re already starting this discussion with the community is great news for all of us. Thank you for that.
June 11, 2011 at 10:01 am
Java SE 7 Vote « London Java Community Blog
[…] a blog post about it here: https://londonjavacommunity.wordpress.com/2011/05/27/the-jcp-reform-and-what-it-means-for-the-java-de… if you missed the announcement and would like to find out more about what all of this […]
June 16, 2011 at 8:48 am
Antti Virtanen
As for the discussions and workgroups on some JSR’s being private or semi-.private, one must consider that not all feedback is useful or constructive. It is ofcourse nice if joining is easy provided you have something valuable to contribute. It is also a good thing to be able to see what people are working on.
Many Java developers have strong opinions about closures and lambdas and many other things, but flooding the JSR mailing lists with all of these opinions would mean very poor signal/noise ratio and thus would nullify the purpose of the mailing list.
Looking forward to what this move means for the progress and future of Java.