Adopt-a-JSR for Java EE 7 - Getting Started
- by arungupta
Adopt-a-JSR
is an initiative started by JUG leaders to encourage JUG members to
get involved in a JSR, in order to increase grass roots
participation. This allows JUG members to provide early feedback to
specifications before they are finalized in the JCP. The standards
in turn become more complete and developer-friendly after getting
feedback from a wide variety of audience. adoptajsr.org
provide more details about the logistics and benefits for you and
your JUG. A similar activity was conducted for OpenJDK
as well. Markus
Eisele also provide a great introduction to the program (in
German).
Java EE 7 (JSR 342)
is scheduled to go final in Q2 2013. There are several new JSRs that
are getting included in the platform (e.g. WebSocket, JSON, and
Batch), a few existing ones are getting an overhaul (e.g. JAX-RS 2
and JMS 2), and several other getting minor updates (e.g. JPA 2.1
and Servlets 3.1). Each Java EE 7 JSR can leverage your expertise
and would love your JUG to adopt a JSR.
What does it mean to adopt a JSR ?
Your JUG is going to identify a particular JSR, or multiple
JSRs, that is of interest to the JUG members. This is mostly
done by polling/discussing on your local JUG members list.
Your JUG will download and review the specification(s) and
javadocs for clarity and completeness. The complete set of Java
EE 7 specifications, their download links, and EG archives are listed
here. glassfish.org/adoptajsr
provide specific areas where different specification leads are
looking for feedback.
Your JUG can then think of a sample application that can be
built using the chosen specification(s). An existing use case
(from work or a personal hobby project) may be chosen to be
implemented instead. This is where your creativity and
uniqueness comes into play.
Most of the implementations are already integrated in GlassFish 4
and others will be integrated soon. You can also explore integration
of multiple technologies and provide feedback on the simplicity and
ease-of-use of the programming model. Especially look for
integration with existing Java EE technologies and see if you find
any discrepancies. Report any missing features that may be included
in future release of the specification.
The most important part is to provide feedback by filing bugs on the
corresponding
spec or RI project. Any thing that is not clear either in the
spec or implementation should be filed as a bug. This is what will
ensure that specification and implementation leads are getting the
required feedback and improving the quality of the final deliverable
of the JSR.
How do I get started ?
A simple way to get started can be achieved by following S.M.A.R.T.
as explained below.
Specific
Identify who all will be involved ? What
would you like to accomplish ? For example, even though
building a sample app will provide real-world validity of
the API but because of time constraints you may identify
that reviewing the specification and javadocs only can be
accomplished. Establish a time frame by which the activities
need to be complete.
Measurable
Define a success for metrics. For example,
this could be the number of bugs filed. Remember, quality of
bugs is more important that quantity of bugs. Define your
end goal, for example, reviewing 4 chapters of the
specification or completing the sample application. Create a
dashboard that will highlight your JUG's contribution to
this effort.
Attainable
Make sure JUG members understand the time
commitment required for providing feedback. This can vary
based upon the level of involvement (any is good!) and the
number of specifications picked. adoptajsr.org
defines different categories of involvement. Once again, any
level of involvement is good. Just reviewing a chapter, a
section, or javadocs for your usecase is helpful.
Relevant
Pick JSRs that JUG members are willing and
able to work. If the JUG members are not interested then
they might loose motivation half-way through. The "able"
part is tricky as you can always stretch yourself and learn
a new skill ;-)
Time-bound
Define a time table of activities with
clearly defined tasks. A tentative time table may look like:
Dec 25: Discuss and agree upon the specifications with JUG
Jan 1: Start Adopt-a-JSR for Java EE 7
Jan 15: Initial spec reading complete. Keep thinking through
the application that will be implemented.
Jan 22: Early design of the sample application is ready
Jan 29: JUG members agree upon the application
Next 4 weeks: Implement the application
Of course, you'll need to alter this based upon your
commitment. Maintaining an activity dashboard will help you
monitor and track the progress.
Make sure to keep filing bugs through out the process!
12 JUGs from around the world (SouJava, Campinas
JUG, Chennai JUG, London Java
Community, BeJUG,
Morocco JUG, Peru JUG, Indonesia JUG, Congo
JUG, Silicon Valley
JUG, Madrid
JUG, and Houston
JUG) have already adopted one of the Java EE 7 JSRs. I'm
already helping some JUGs bootstrap and would love to help your JUG
too.
What are you waiting for ?
