Adopt a JSR Program
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 JavaEE 7 APIs for the cloud and much more! This program will realise the following benefits:
- 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)
The benefits to JUGs and individual members adopting a JSR are hopefully obvious. It looks great on the CV, gives you new technical and community skills and much more!
With JSR-348 bringing openness and transparency to the way in which JSRs are run, this is a great opportunity for all of us to help the Java ecosystem thrive.
An overall guideline for this program is that we want to gather up the enthusiasm and skill sets of Java developers around the world, but then focus their efforts at specific areas within JSRs. For example, this means that for the latest complex language features in Java 8 we'll encourage most 'Adopt a JSR' members to try the latest builds, evangelise the betas to major open source projects and to provide feedback on day-to-day usage. A smaller number of JUG members who are really qualified in the area of language design (if you think syntax is the important bit, then this probably isn't you) will be encouraged to contribute more directly. This of course includes enthusiasts who are willing to put in the time to really learn about this stuff. As Yara from SouJava pointed out at Devoxx, this is a great opportunity to also mentor budding experts in the various JSRs, so that there is a path for those who want to travel it.
How to get Started
Any time you need help please mail the JUG leaders list
- Optional - Make sure that your JUG is a member of the JCP
- If not then get your leader to add your Java User Group
- Optional - Join the JCP as an individual member. This is optional, because the openness and transparency rules that make up JSR-348 have been applied to most JSRs now. However, you need to do this in order to contribute any code + you get voting rights and other benefits with this membership!
- Mandatory - Sign the JSPA - This is a required step as part of joining as any of your contributions that might contain Intellectual Property (IP), needs permission in order to go into the JSR (e.g. The API design for a couple of methods that you wrote for your company).
- Optional - Associate yourself with your JUG (assuming your JUG has registered itself).
- Explore the JCP website to get a feel for the process of how JSRs work and what JSRs are currently out there.
- Have a read of The new JCP Process for JSRs.
- Sign-up to the Executive Committee (EC) alias here
- Join the local group within your JUG for each JSR that you are interested in.
- If one doesn't exist then create one!
See Managing the Adopt a JSR program to go forward from there!
Who's Adopting JSRs?
The Grids below indicate which JUGs are working or have worked on a JSR.
NOTE: Multiple JUGs can and should collaborate on a particular JSR! there's always plenty of work to do and it can be easily distributed.
JSRs being worked on
|JUG||JSR-310 (Date and Time)||JSR-321 (Trusted Computing)||JSR-331 (Constraints Programming)||JSR 335 (Lambda Expressions)||JSR 339 (JAX-RS 2.0)||JSR-343 (JMS 2.0)||JSR 344 (JSF 2.2)||JSR 346 (CDI 1.1)||JSR-347 (Data Grids)||JSR-349 (Bean Validation 1.1)||JSR-350 (Session State management)||JSR-351 (Identity Management)||JSR-352 (Batch processing)||JSR-353 (JSON API)|
|LJC||310 Page||335 Link TBA
||339 Link TBA
||347 Link TBA
||353 Link TBA
Managing the Adopt a JSR program
Every JUG will want to work differently, all we can suggest is that you put together a wiki similar to LJC's Adopt a JSR Program and for each JSR, a wiki similar to LJC's Adoption page for JSR-310 - New Date and Time.
Leading an Adopt a JSR group
This section (taken from Somay Nakhal's work) contains some guidance for JUG members who are leading an Adopt a JSR group as used by the LJC. Take as much or as little of it as you need!
Once a group has really gotten going the leader(s) of the Adopt a JSR group might find it useful to:
- Create a wiki page for your efforts, e.g. LJC JSR-310 page
- This wiki can contain the links to resources such as the JSR project page (typically a java.net projects), mailing lists, conference talks, presentations downloads... etc related to the JSR
- Add the link to this on the JSR wiki page on the Global JUG Matrix at http://java.net/projects/jugs/pages/AdoptAJSR
- Contact the Spec Lead for the JSR, introducing yourself and explaining your JUGs intended involvment.
- Send an initial email to interested adoptees
- Introduce yourself and why you are interested in the JSR
- Briefly explain the JCP process (depending on the familiarity of the adoptees)
- Talk about the JSR and it's current state
- Ask them to introduce themselves and why they are interested in the JSR
- Ask interested adoptees to check the details on the Adopt a JSR page and provide their opinion.
- Identify areas where the JSR needs help / or areas that your group want to work on.
- Co-ordinate your activities with the spec lead and expert group on the official JSR mailing lists.
- Encourage genuine experts within the adoptees to join the Expert Group.
- Email the adoptees about updates related to the JSR: eg voting results, availability of drafts...etc.
Some other miscellaneous things you can do are:
- Give lighting talk(s) about the subject matter and the JSR by yourself/adoptees.
- Arrange F2F hackdays/meet-ups to work on the JSR
How do you plan what has to be done/fixed for certain JSR?
In London each little group does it their own way, some meet F2F, some do it over email, others have Skype sessions. Whatever way works with your group is fine.
The tasks that we deal with in London typically fall into two categories:
- An analysis of whether the JSR meets the principles of JSR-348. This is important as it partly determines how the LJC vote on that JSR (since we hold an EC seat, we have a vote).
- Other stuff - The Adopt a JSR team will typically take a look at the JSR and ask the Spec Lead / Expert Group what help they require. This can be helping out with:
- Coding parts of the RI/TCK
- Evangelising the JSR on social media
- Testing early versions of the RI
- Helping answer questions on a mailing list
- Helping set-up project infrastructure (e.g. Setting up JIRA on the JSR project on java.net)
- And more!
What do we do for SCM, Issue tracking, CI etc?
Each JSR should run its own infrastructure (the Spec lead / EG will have the details), the Adopt a JSR volunteers should simply use that.
How is it with deadlines? JRS should have some preliminary "release" date, how this is set and followed up?
You'll find the deadlines on the official JSR page at JCP.org for each JSR. The LJC and the JCP.org folks are working on a calendar that can be shared that has these dates on it.
Again, any questions, comments etc send to the JUG leaders list
Back to Home