New Java Community Process (JCP) Membership Types and What They Mean

Last year the Java Community Process (JCP) introduced a couple of pretty important new membership types. Ever since Java EE 5 the community has played a larger and larger role certainly in shaping Java EE standards and these new membership types are important enablers in the same direction. In this post I'll explain the new membership types and what they actually mean. I'll also explain how I and the Philly JUG have used these new membership types.

The Existing Membership Types
Before getting into the new membership types I think it helps to explain what the existing membership types were. Before last year there was really two ways of joining the JCP - either as a company or as an individual. Company membership types are the original kind of JCP membership type. As scary as it is, this is basically the most common membership type for most standards bodies out there (yikes). Thankfully this has been the least common type of JCP membership for a long time.

However, even if you did want to join the JCP as an individual, you needed official permission from your company. This is a real hurdle for many people and I personally know of cases where people could not join the JCP exactly for this reason. As a long-time self-employed independent consultant this was a non-issue for me (I simply had to give myself permission to join :-)). This is how I served as an expert on the EJB 3.1, Java EE 6, JMS 2, Java EE 7 and EJB 3.2 expert groups. I believe I have been one of the most active members of those expert groups.

Either as an individual or a company, you are basically considered a "full member". That means you can do pretty much anything in the JCP - including submitting your own JSR, becoming a specification lead, becoming an expert or running for a spot on the executive committee. In case you are wondering this also includes legally recognized non-profits like Apache.

Associate Member
The new Associate membership type is basically the same as the individual membership I've used for such a long time with one big exception. In order to join as an Associate member, you don't actually need permission from your company. This does come with some limitations that I don't think matter that much. You can't become a specification lead. You can't run for the JCP executive committee. Indeed you don't get to be an "expert" on a JSR either. You can however become a "contributor" to a JSR.

In practice the difference between a "contributor" and an "expert" on a JSR is pretty meaningless for most people. As a mere "contributor" you basically can't write specification text or contribute code to the compatibility tests (TCK) or the reference implementation (RI). You can do everything else like review specification work and participate in discussions. The truth of the matter is that I am one of the most active contributors in most of the Java EE JSRs I have been on and this is basically all I did anyway. As a result, I've actually chosen to join the JCP as an Associate member instead of  a full member for this reason. I am now a "contributor" to Servlet 4, Java EE 8 and Java EE Security. I still get to do exactly what I've done for years and get credit for it in the specification document.

To be honest, it would have been easy enough for me to get permission from my company to join as a full member. The reason I chose not to do that is because there wasn't a need and I also wanted to encourage others to do exactly what I did. This is particularly important for JUGs and Adopt-a-JSR. I'll explain more in the next few sections why this is.

Partner Member
Besides joining as a fully legally recognized entity, non-profits can now also join as Partner members. Very simply put, this is basically intended for Java user groups. Many of the larger Java user groups are actually legally recognized non-profits. For these JUGs, joining as full members is perfectly fine. Most JUGs in the world are not legally recognized entities. These JUGs can now join the JCP as Partner members. Partner members do have limitations. They can't become specification leads. They can't even join a JSR as an expert or a contributor. They can however do one very important thing - run for a seat in the JCP executive committee.

At the Philly JUG, we did not opt to become a legal entity yet. It's just too much hassle with not enough of a benefit for us. As a result, the Philly JUG has joined the JCP as a Partner member. We are not running for the JCP executive committee yet, but we might.

Adopt-a-JSR
It's important to understand how all of this relates to Adopt-a-JSR. The first thing to understand is that you can participate in Adopt-a-JSR without even being a member of the JCP. The issue is that you really don't get recognized in the specification itself as either a contributor or an expert (but the lead still can make a special mention if they want). Your JUG does get listed on the Adopt-a-JSR JUGs page.

A much better way to go is to adopt a JSR, get your JUG registered as a JCP Partner member and get JUG members to become official contributors to the JSRs you are adopting as JCP Associates. This can all be done without any company being involved. This is exactly what the Philly JUG has done. The Philly JUG is now an adopter of Java SE 9, Servlet 4, Java EE 8 as well as Java EE Security.

I hope this writeup inspires you to join the JCP using the new membership types. In the many years that I've worked in the JCP, the oddest part has been the tiny number of exceptional people that actually participate actively. This really needs to change if Java is to remain successful. You need to be a part of that change.

If you have any questions on any of this, don't hesitate to reach out. I'll try to help as much as I can. One resource that might help is the JCP page on membership types.