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
||346 Link TBA
||347 Link TBA
||353 Link TBA
|SouJava||310 Link TBA
||335 Link TBA
||339 Link TBA
||344 Link TBA
||349 Link TBA
||352 Link TBA
||353 Link TBA
Managing/Leading the Adopt a JSR program
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.
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.
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?
The tasks that we deal with in London typically fall into three categories, starter, intermediate and advanced. The Adopt a JSR team will typically take a look at the JSR and ask the Spec Lead / Expert Group what help they require and/or volunteer for an area that they find particularly interesting.
- Test the early Reference Implementation builds
- Use them to find pain points (“It’s just too laborious to construct X”)
- Report bugs (“Arggh NPE!!”)
- Suggest feature enhancements (“A convertX method would help”)
- Help triage issues
- Reproduce issues
- Erase/merge duplicates
- Set priorities/categories etc
- Give feedback on design (remember semantics is more important than syntax!)
- Discuss issues with your JUG and deliver feedback
- Think about how you would use the JSR as a day to day developer
- Help moderate the mailing lists
- Help the community self police towards helpful conversations
- Pour water on flame wars etc
- Help evangelise the JSR
- Social media (twitter, facebook et al)
- Blogging (write a post about the JSR)
- Lightning talks (give a talk at your user group or online!)
- Improve project infrastructure and JSR visibility
- Help setup canned hosting (java.net, GitHub etc)
- Help with SEO of website
- Make sure that downloads, mailing lists and issue trackers are easy to find
- Help maintain their FAQ/Wiki
- Help the JSR meet the principles of JSR-348.
- Is there a public issue tracker?
- Does the EG communicate on a public mailing list?
- Is the EG balanced?
- Is the std a coming together of competing implementations?
- This is especially important to the LJC as it partly determines how the LJC vote on that JSR (since we hold an EC seat, we have a vote).
- Help build the RI
- Get coding with the actual implementation of the spec!
- Help build the TCK
- All implementations must pass this crucial test suite
- Great way to gain real TDD/Unit/Integration test experience
- Join the Expert Group (EG)
- You need to be an expert in this technology
- EG members are central to pushing the JSR forwards
- High time commitment
- Lots of personal, community and career benefits
- Become the Spec Lead for a JSR
- You need to be a leading expert in a particular technology
- Considerable time commitment
- International recognition for your work
- Join the Executive Committee
- High time commitment
- Influence all standards
We're coding! What do we do for Version Control, 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?
You'll find the deadlines on the official JSR page at JCP.org for each JSR. The Spec Lead and EG will be able to guide you on the deadlines they are working towards.
Again, any questions, comments etc send to the JUG leaders list
Back to Home