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 Martijn 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 friendly APIs
- 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 issues etc)
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 project 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.