Adopt a JSR initiative aims to encourage grass roots participation
45% say JSR quality and speed will improve with the scheme implemented.
Despite both seemingly being around since Java’s infancy, Java
User Groups and Java Specification Requests haven’t always been the
happiest of bedfellows. Whilst some have actively been engaging
with specific projects from the beginning, others have shied away
from it for many a year, with cooperation really only taking off in
recent years. As Kevin Farnham points out in his
blog, the Java Community Process was often seen as remote to
the community itself.
Perhaps now some have realised the benefits of an outsider
applying his or her knowledge when a project reaches a stumbling
block. Only through cooperation of the two distinct entities can
the Java ecosystem progress further and creative a fervent breeding
ground for innovation.
One man who has championed the cause for more collusion is
Verburg with the ‘Adopt a JSR’ initative. He says:
This program is intended to encourage JUG members to get
involved in a Java Specification Request (JSR) and to evangelise
that JSR to their JUG and the wider Java community in order to
increase grass roots participation. JSRs cover all aspects of the
Java ecosystem such as the new Date and Time API coming into Java
8, the latest JEE7 APIs for the cloud and much more!
Variety certainly adds spice to this project, with user groups
being able to choose the JSR that most relates to their
specialities. The benefits to signing up should be fairly visible
from the outset – for example how it looks on the CV and the
opportunity to garner key Java contacts, but here’s a few more that
Martijn has outlined.
- Standards get earlier feedback, leading to more developer
- Standards get ‘end user/developer’ expert input
- Standards get developed faster as we can help with some of the
heavy lifting of building Reference Implementations (RI) and
Technical Compatibility Kits (TCK)
- JUGs can help with the management of the open source project
that springs up around a JSR (managing mailing lists, triaging
In the grand scheme of things, this collaboration can only
serve to help Java progress and also strive in relation to JSR-348
‘Towards a new version of the Java Community Process’. Two user
groups that have already adopted a JSR include the London Java
Community who were at the forefront of
JSR-310 Date and Time, ensuring an API will be in place for
Java 8, and also the Houston JUG’s work towards standardising grid
data space (JSR-347).
Martjn provides a helpful guide to getting started within the
page for those wondering how they can commit to the
project as quickly as possible.
Initial reaction to Verburg’s project appears to be quite
positive, with 45% of those voting in a poll agreeing
that both JSR overall quality and progression would benefit hugely.
There were some yet to be convinced though, stating that involving
more developers is a bad idea. From the outset, they may have a
point – maybe too many cooks do spoil the broth and create artistic
confusion. But surely with a greater presence from the community,
the drive towards transparency from the JCP can ultimately be
achieved, no matter how slowly.