1. The JCP program
More than 101 ways to influence the
future of Java
Patrick Curran and Heather Vancura
http://jcp.org
1 November 2012

2. Welcome!
2

3. Agenda
• Why standards are important
• How we create standards for Java
• How the JCP is changing
• How you can get involved
3

4. Languages & protocols
4

5. Interfaces
5

6. Specifications
6

7. Blueprints
7

8. Certification
8

9. No vendor lock-in
9

10. Industrial-strength systems
10

11. Java standards
11

12. Java SE
12

13. Java ME
13

14. Java EE
14

15. How the JCP works
15

16. How we do it
• Java Specification Requests (JSRs)
• A JSR is a single version of a Java specification.
• JSRs are led by a community member (the Spec Lead),
with a group of interested members (the Expert Group)
helping with the day-to-day decisions and work.
• Any JCP member can submit and lead a JSR.
• Each Expert Group must deliver:
• The Specification
• A Reference Implementation (RI)
• A Technology Compatibility Kit (TCK)
16

17. The compatibility triangle
• Specification
Is the specification Can you build an
unambiguous? implementation?
Technology Compatibility Reference Implementation
Kit
Is the TCK correct?
Does the RI conform?
17

18. Guilds
18

19. Quality-control
19

20. A Silversmith’s hallmark
20

21. Compatibility testing
21

22. The Java hallmark
22

23. Organization
23

24. Legal framework and governance
• Java Specification Participation Agreement (JSPA)
• A legal contract between members and Oracle.
• Addresses Intellectual Property (IP) grants and the terms
under which the spec, RI, and TCK should be licensed.
• http://www.jcp.org/aboutJava/communityprocess/JSPA2.pdf.
• The Process Document
• Defines the governance of the organization.
• Defines the processes that are used to submit define,
develop, review, approve, and maintain specifications.
• Defines the obligations to produce an RI and TCK.
• http://jcp.org/en/procedures/jcp2.
24

25. Roles
• JCP Chair
• Leads the organization and manages the PMO.
• Program Management Office (PMO)
• Manages day-to-day operations of the organization.
• Executive Committee
• Votes on JSRs at defined stages through the process.
• Defines JCP governance, processes, and contractual terms
of membership.
• Expert Groups
• Create JSRs (write the spec, develop the RI and TCK.)
• Members
• Review specs, may participate in Expert Groups, vote in
Executive Committee elections.
25

26. The Executive Committee
• JSR 355 has merged the two previous Executive
Committees (one for Java ME and one for Java SE & Java
EE combined) into a single Committee.
• The EC Meets approximately monthly by phone, 3 times a
year face-to-face.
• Meeting minutes and materials are public.
• See http://jcp.org/en/resources/EC_summaries.
• We hold two public teleconferences and one public f2f
meeting each year.
• We have a public mailing list for feedback.
• Sign up at http://java.net/projects/jcp-ec/lists.
26

27. Executive Committee elections
• When the EC Merge is completed in October 2013 the EC
will have 25 members.
• Oracle has a permanent seat.
• There are 16 ratified seats.
• Oracle nominates candidates.
• The entire JCP membership must approve via ballot.
• The remaining 8 seats are elected (any JCP member may
nominate themselves.)
• Yearly elections reconfirm or replace half of the members.
• Special elections are held to fill seats vacated by resignation.
27

28. Executive Committee responsibilities
• Review and vote on all JSRs as they work through the
process.
• Evolve the JSPA and the Process Document.
• The JSPA and Process Document are modified through the
JSR process itself.
• The Executive Committee serves as the Expert Group for
JSRs that make these changes; the Chair is the Spec Lead.
• JSR 99 originally defined the JSPA.
• JSR 215 originally defined the Process Document.
• A series of JSRs (collectively called JCP.next) is making
further changes to the process.
• More on this later.
28

29. Executive Committee membership
Stefano Andreani Aplix ARM
Azul Systems Cinterion CloudBees
Credit Suisse Eclipse Ericsson
Fujitsu Goldman Sachs Google
HP IBM Intel
Werner Keil London Java Community Nokia
Oracle Red Hat SAP
SouJava TOTVS Twitter
Members listed in red are new to the EC as of November 2012.
29

30. The Spec Lead
• The individual or institutional owner and driver of a JSR.
• Recruits and organizes the activities of the Expert Group.
• Responsible for delivering the Spec, RI, and TCK.
• Intellectual Property rights to the technology incorporated
in the JSR accrue to the Spec Lead.
• Subject to obligations incurred under the JSPA.
• The Spec Lead is free to define the terms under which the
RI, and TCK will be licensed.
• Subject to obligations incurred under the JSPA.
• Oracle is the Spec Lead for the three existing Platforms:
Java ME, Java SE, and Java EE.
30

31. The Expert Group
• The Expert Group is recruited and led by the Spec Lead.
• All members of the JCP are eligible to join.
• Participation by all interested parties is encouraged and
desirable.
• The EG works as a team to define the JSR and to develop
the Spec.
• The RI and TCK are the Spec Lead’s responsibility.
• The Expert Group must operate transparently, so that JCP
members and the public can review and participate in its
work.
31

32. The membership
• Anyone can join.
• Total membership is approximately 1200.
• 3700 registered users at jcp.org.
• Fees:
• Java Licensees: free.
• Individuals: free
• Java User Groups: free.
• Non-profit organizations: $2K/year.
• Commercial organizations: $5K/year.
32

33. Who are the members?
• Membership distribution by type:
• 77% individual.
• 21% corporate.
• 2% non-profit.
• Membership distribution by location:
• 50% North America.
• 32% Europe and the Russian Federation.
• 13% Asia and the Middle East.
• 5% South America.
33

34. The JSR development cycle
34

35. JSR Submission
• Identify the submitters, the Specification Lead(s), and the
initial members of the Expert Group.
• Describe the proposed specification and the reasons for
developing it.
• Identify the target Platform(s).
• Estimate the development schedule.
• Describe the working model the Expert Group will adopt,
and how it will involve the community and the public.
• Identify preexisting documents, technology descriptions,
or implementations that might be used as a starting point.
• Publish the licensing terms for the Spec, RI, and TCK.
35

36. JSR Review and Approval Ballot
• JSR proposals are published on the JCP website.
• JCP members, the Executive Committee, and the public
review and comment.
• JCP members may request to join the Expert Group
during this period.
• The Executive Committee votes on the JSR after the
review period.
• If the JSR is voted down, submitters have 14 days to
revise and resubmit for a second vote; if this fails the JSR
is closed.
36

37. Expert Group formation
• Expert Group formation begins when the JSR is approved.
• Members request to join the EG through an online form.
• No size limit; Spec Leads should ensure that all interested
parties are represented, but should keep the group small
enough that it will be able to function efficiently.
• Members may be added at any time, subject to the
agreement of the existing membership.
• The EG decides its mode of operation (communication
mechanisms, meeting schedules, etc.)
• Transparency and community involvement are required.
37

38. Early Draft
• The Expert Group's first deliverable is the Early Draft.
• Provides the JCP membership and the public with a draft
that is detailed enough to generate useful feedback.
• No fixed deadline for generating the draft – EGs should
take as long as they need (but no longer!)
• Early Draft is published for review on the JCP website.
• Review period is typically 30 days but may be longer.
• No ballot at this stage – the purpose is to gather feedback.
• EGs may choose to revise the draft and resubmit if
feedback indicates that significant changes need to be
made.
• OK to iterate through several Early Draft reviews.
38

39. Public Review
• Spec should be relatively complete before Public Review.
• Expert Group should also be developing the RI and TCK
while working on the spec.
• Spec is published for review on the JCP website.
• Review period is 30–90 days (the EG decides how
long).
• All public comments should be considered and addressed.
• The Public Draft Specification Approval Ballot takes
place during the final 7 days of the review
• If the ballot fails, the EG has 30 days to resubmit for a
Reconsideration Ballot.
• If this ballot fails, the JSR is closed.
39

40. Proposed Final Draft
• The EG submits a Proposed Final Draft of the spec to the
PMO.
• This should incorporate and address feedback from the
Public Review.
• Spec is posted on the website for public download.
40

41. Final Approval and Release
• The EG prepares the Final Draft of the spec and completes
the RI and TCK.
• The TCK must meet quality and coverage goals.
• The RI must pass the TCK.
• A test appeals process must be defined.
• Final RI and TCK licensing terms must be published.
• The EC has two weeks to review these materials and to
cast their votes in the Final Approval Ballot.
• If the ballot fails the EG has 30 days to resubmit for a
Reconsideration Ballot; if that fails, the JSR is closed.
• Approved JSRs are posted for Final Release and may then
be implemented commercially.
41

42. Maintenance
• Spec Leads are expected to make a long-term commitment
to revise and update the spec, RI, and TCK.
• The Spec Lead typically takes on the role of Maintenance
Lead.
• Reviews proposed changes in the Issue Tracker and
decides which are to be included in the Maintenance
Release.
• 30-day public Maintenance Review period followed by a
seven-day ballot.
• When the Spec, RI, and TCK are updated and published, the
Maintenance Release is completed.
42

43. Summary of JSR stages
• JSRR: JSR Review - Mandatory - 2 or 4 weeks.
• JAB: JSR Approval Ballot - Mandatory - 2 weeks.
• EDR: Early Draft Review - Mandatory - 30/45/60/90 days.
• PR: Public Review - Mandatory - 30/45/60/90 days.
• PRB: Public Review Ballot – Mandatory - 7 days.
• PFD: Proposed Final Draft - Mandatory - no time frame.
• FAB: Final Approval Ballot - Mandatory - 2 weeks.
• FR: Final Release - Mandatory.
• MR: Maintenance Review - Mandatory – 30 days.
• MRB: Maintenance Review Ballot - Mandatory – one week.
• MREL: Maintenance Release - Mandatory.
Each stage must be completed before the EG moves on to the next.
43

44. Constitutional change (JCP.next)
44

45. Using the Process to change the Process
• We modify the Process (as defined in the Process Document
and the JSPA) by filing JSRs.
• The Chair is the Spec Lead, and the Executive Committee
members form the Expert Group.
• Process-change JSRs go through all of the same stages as
regular JSRs.
• The output is a new version of the Process Document and/or
the JSPA.
45

46. JCP.next
• A series of three JSRs:
• JSR 348: Towards a new version of the Java Community
Process completed in October 2011.
• This JSR focused on relatively simple changes that we were able
to implement within about six months.
• JSR 355: Executive Committee Merge completed in August
2012.
• Implementation began in October 2012 and will be completed
in October 2013.
• JSR 358: A major revision of the Java Community Process is in
progress now.
• This JSR will implement more complex changes and will
modify the JSPA as well as the Process Document.
46

47. JCP.next.1 (JSR 348)
47

48. A limited and focused JSR
• JSR 348 was deliberately focused on relatively simple changes
that we were able to implement within about six months.
• All complex matters, including anything that would require
modifying the JSPA, were postponed until JCP.next.3.
• The JSR was completed within 6 months and implemented a
number of important changes in the following areas:
• Transparency.
• Participation.
• Agility.
• More on this later...
48

49. JCP.next.2 (JSR 355)
49

50. JSR 355 (the EC merge)
• Because Java is One Platform, and because we expect ME
and SE to converge over time, JSR 355 was introduced to
merge the two Executive Committees into one.
• This JSR will reduce the number of EC members and keep the
same ratio (2:1) of ratified and elected seats.
• Oracle will give up one of its permanent seats.
• No other member may hold more than one seat.
• No other significant changes to our processes.
50

51. Implementation plan
• Reduce the size of the merged EC to 25 members.
• Merge the ECs after the 2012 election and eliminate Oracle
and IBM's second seats at this time.*
• Allow members elected in 2010 to serve their full terms (until
2013) and then eliminate the remaining seats.
• All members must stand for re-election in 2013.
• Reconsider the goal of 25 seats before the 2013 election – if
we need to change this, do so with a Maintenance Release of
JSR 355.
• Switch to a two-year election cycle after 2013.
* After the 2012 elections we have several ratified seats “in reserve” for
next year.
51

52. That was easy!
52

53. JCP.next.3 (JSR 358)
53

54. Modifying the JSPA
• The JSPA has not been significantly modified since 2002.
(some minor changes were introduced in 2005.)
• Since then the organization and the environment in which we
operate have changed significantly.
• The document is due for updating and clean up.
• However, it is extremely complex and difficult to understand.
• We must be very careful when making changes.
• Plus…
54

55. All the lawyers will get involved
55

56. Our shopping list
•Intellectual Property (IP) flow.
•Compatibility policy.
•Licensing and open-source.
•Independent implementations.
•The role of the RI.
•The role of individuals.
•Transparency.
•Refactoring the JSPA.
•Fee structure.
•And lots more (see the Issue Tracker for the full list.)
56

57. Why it matters
• The JSPA is the foundation of the Java ecosystem.
• It defines the way in which IP is granted and the terms under
which the spec, RI, and TCK must be licensed.
• The JSPA ensures:
• that implementations of Java are compatible,
• that the technologies we incorporate into Java are “safe”
from an IP perspective (we know who owns them,)
• that people can implement them and use them with
confidence.
57

58. Follow us on java.net
• As JSR 348 mandates, all our work is carried out in public.
• Start with our public java.net project.
• There you will find links to:
• The Observer mailing list (all Expert Group mail is copied
here.)
• The Issue Tracker.
• The Document Archive (meeting agendas and minutes, task
lists, and working drafts are published here.)
58

59. And so...
59

60. Putting the community back into the JCP
• No more barriers to participation.
• All members of the Java community can participate:
• In the implemenation of the platform through OpenJDK and
GlassFish.
• In the evolution of the platform through the JCP.
• If you care about the future of Java you have no excuse...
60

61. JCP.next.1 (JSR 348)
• Transparency
• Participation
• Agility
61

62. Transparency
62

63. Expert Group transparency
• Must do all substantive business on a public mailing list.
• Must track issues in a public issue tracker.
• Members of the public must be able to comment on the EG's
work.
• The EG must publicly respond to all comments.
• License terms must be fully disclosed in advance.
63

64. Executive Committee transparency
• Must hold semi-annual teleconferences and an annual open
meeting at JavaOne.
• All JCP members are free to attend these meetings.
• Agenda will be chosen from topics suggested by members.
• Must create a public mailing-list with archive for members to
provide feedback to the ECs.
• Private and non-normative EC policies and procedures made
public and normative in new EC Standing Rules.
• Escalation and Appeal process defined.
• Spec Leads, EG members and JCP members can appeal to
the EC for help in resolving disputes.
64

65. Participation
65

66. Participation
• Requests to join EGs, the Spec Lead's responses, and
decisions to remove or replace EG members, must be
reported on the EG's public alias.
• Better processes for dealing with uncooperative,
unresponsive, or disruptive EG members and Spec Leads.
• EC members who miss two consecutive meetings lose their
voting privileges until they have again attended two.
• EC members who miss 5 meetings in a row or 2/3 of the
meetings in a 12 month period lose their seat.
• Several non-participating EC members lost their seats in
2012.
66

67. Agility
67

68. Agility
• Time-outs for inactive JSRs.
• Must reach Early Draft within 9 months, Public Draft one
year after that, or Final Release within another year.
• If not, the EC can initiate a JSR Renewal Ballot and may
vote to withdraw the JSR.
• Simplify the Maintenance Release process.
• Clarify the Final Release and Maintenance processes to
ensure that completed/updated Spec, RI, and TCK are posted
promptly.
• Ensure that links to RI and TCK are maintained.
• If broken and not fixed, JSR must revert to “incomplete”
stage.
68

69. Results...
• JSR 348 introduced version 2.8 of the Process.
• It is now easier for JCP members and the public to observe
and participate in the work of Expert Groups.
• Transparency is the default mode of operation.
• All new JSRs will be bound by the new rules.
• Existing JSRs will be encouraged to voluntarily adopt them.
• Now we need your participation!
69

70. JCP 2.8 progress report
• JCP 2.8 went into effect in October 2011.
• All JSRs started since then are run under this version of the
Process.
• Spec-Leads of in-flight JSRs are encouraged to voluntarily
adopt the new Process.
• On doing so they are required to operate transparently, and
become subject to the new JSR deadlines.
70

71. JCP 2.8 adoption
• There are 30 Active/In Progress JSRs.
• 22 Active JSRs are operating under version 2.8.
• No Renewal Ballots yet.
• 10 JSRs have been initiated under JCP 2.8 (1 was rejected.)
• 13 JSRs have migrated to JCP 2.8.
• 2 JSRs are in the process of migration to JCP 2.8.
• 7 in-flight Active JSRs have not yet migrated.
• Excluding those that have already posted a Final or
Maintenance Release.
• The PMO encourages Spec Leads to migrate at milestone
postings.
71

72. New JCP 2.8 JSRs
• JSR 352, Batch Applications for the Java Platform (IBM) – PR, November
2012.
• JSR 353, Java API for JSON Processing (Oracle) – EDR, September 2012.
• JSR 354, Money and Currency API (Credit Suisse) – JSR Review, February
2012.
• JSR 355, EC Merge (Oracle) – Final Release, August 2012.
• JSR 356, Java API for WebSocket (Oracle) – EDR, September 2012.
• JSR 358, A major revision of the Java Community Process (Oracle) – JSR
Review, July 2012.
• JSR 359, SIP Servlet 2.0 (Oracle) – JSR Review, July 2012.
• JSR 360, Connected Limited Device Configuration 8 (Oracle) – JSR
Review, October 2012.
• JSR 361, Java ME Embedded Profile (Oracle) – JSR Review, October
2012.
72

73. Migrated JCP 2.8 JSRs (1)
• JSR 172, J2ME Web Services Specification (Oracle) – MR, October
2011.
• JSR 236, Concurrency Utilities for Java EE (Oracle) – EG Formation,
migrated March 2012.
• JSR 338, Java Persistence 2.1 (Oracle) – EDR2, November 2012.
• JSR 339, JAX-RS 2.0: The Java API for RESTful Web Services
(Oracle) – PR, October 2012.
• JSR 340, Java Servlet 3.1 Specification (Oracle) – EDR, August 2012.
• JSR 341, Expression Language 3.0 (Oracle) – PR, August 2012.
• JSR 343, Java Message Service 2.0 (Oracle) – EDR, March 2012.
• JSR 344, JavaServer Faces 2.2 (Oracle) – EDR, December 2011.
• JSR 345, Enterprise JavaBeans 3.2 (Oracle) – EDR, February 2012.
73

74. Migrated JCP 2.8 JSRs (2)
• JSR 346, Contexts and Dependency Injection for Java EE 1.1
(RedHat) – PR, November 2012.
• JSR 335, Lambda Expressions for the JavaProgramming Language
(Oracle) – EDR 2, July 2012.
• JSR 337, Java SE 8 Release Contents (Oracle) – EG Formation,
migrated September 2012.
• JSR 308, Annotations on Java Types (M. Ernst, Oracle) – EDR 2,
February 2012.
74

75. JSRs in the process of adopting JCP
2.8
• JSR 342, Java Platform, Enterprise Edition 7 (Java EE 7)
Specification (Oracle) – EDR2, November 2012.
• JSR 310, Date and Time API (S. Colebourne, M. Santos, Oracle) –
EDR, September 2012.
75

76. JSRs that have not yet adopted JCP
2.8
• JSR 107, JCACHE - Java Temporary Caching API (G Luck, Oracle)
– EDR , October 2012.
• JSR 302, Safety Critical Java Technology (Open Group) – EDR,
January 2011.
• JSR 333, Content Repository API for Java Technology 2.1 (Adobe) –
EDR, September 2011.
• JSR 347, Data Grids for the Java Platform (RedHat) – JSR Review,
April 2011.
• JSR 349, Bean Validation 1.1 (RedHat) – PR, October 2012, JCP 2.7
• JSR 350, Java State Management (Oracle) – JSR Review, August
2011.
• JSR 351, Java Identity API (Oracle) – JSR Review, September 2011.
76

77. Get involved!
77

78. Everyone is welcome
78

79. Why participate?
• As a corporation:
• To influence the technologies that drive your market.
• Because it's cheaper than developing everything yourself.
• To provide opportunities for your developers.
• To increase the size of your market.
• To gain a competitive advantage (ship new products faster.)
• As an individual:
• Good karma!
• Experience.
• Fame and fortune.
79

80. How to participate?
• As an individual – OK.
• As part of a team –
better.
• Work through your
JUG.
• Help each other.
• Teach each other.
• Work with each
other.
80

81. JUG members
BeJUG (Belgium) JUG-EG (Egypt)
BreizhJUG (Brittany) JUGF (Germany)
JUG Indonesia
Central Ohio JUG (USA)
JUG-MK (Macedonia)
Connecticut JUG (USA)
JUG-RU (Russia)
Detroit JUG (USA) JUG-USA
Duchess (Women) London Java Community (UK)
FASOJUG (Burkina Faso) Malaysia-JUG
Houston JUG (USA) MoroccoJUG
iJUG e.V. (Germany) Nashville JUG (United States)
IndiJava (India) Oklahoma City JUG (USA)
Japan JUG Rio JUG (Brazil)
Java Student User Group (Vienna) Riviera JUG (France)
Ruhrjug (Germany)
Java Web User Group (London)
Silicon Valley JavaFX User Group
Jozi JUG (South Africa)
(USA)
JUG-AFRICA SouJava (Brazil)
JUG Chennai (India) Utah JUG (USA)
81
Vancouver Island JUG (Canada)

82. JUG representation on the EC
• SouJava (Bruno Souza, Fabio Velloso, Yara Senger):
• Nominated by Oracle to a ratified seat on the SE/EE EC in the
May 2011 Special Election.
• London Java Community (Ben Evans, Martijn Verburg, Trisha
Gee):
• Won an elected seat on the SE/EE EC in the May 2011 Special
Election and re-elected in 2012.
• Both have already made significant contributions to the work of
the JCP.
82

83. Adopt a JSR!
Thank you and
83

84. What is it?
• A JUG-lead initiative to improve Java standards.
• Groups of JUG members work on JSRs.
• See http://java.net/projects/adoptajsr for full details.
84

85. Why should JUGs get involved?
• To move the entire Java ecosystem forward.
• To speed up the standards-development process.
• To become part of the solution as opposed to staying silent.
• To be at the forefront of new technology.
• To ensure that Java standards are practical and relevant for
the real world as opposed to the ivory tower.
• We need expert input from end-users and developers.
• To ensure that Java standards are truly global.
• We need expert input from non-English speakers.
85

86. How can you join?
• Contact your local JUG leader, or...
• Go to http://java.net/projects/adoptajsr and follow the
simple set-up steps described there:
• Join the AdoptAJSR project.
• Sign up for the mailing list.
86

87. How can you help?
• Help to moderate the mailing lists; steer towards
helpful conversations
• Evangelize the JSR through social media, blogging
or lightning talks.
• Give a talk at your user group or online.
• Help with documentation.
• Translate into your native language.
• Help to maintain the FAQ/Wiki.
• Improve project infrastructure and JSR visibility.
• Help set up JSR hosting (java.net, GitHub, etc.)
• Help with Search Engine Optimization of website.
• Ensure that downloads, mailing lists, issue trackers
are easy to find.
87

88. How else can you help?
• Test the early RI builds; use them to find pain points,
report bugs, suggest feature enhancements.
• Help triage issues; reproduce issues, erase/merge
duplicates, set priorities/categories etc.
• Give feedback on design; discuss issues and deliver
feedback, think about how you would use the JSR as a
developer.
• Help build the RI; get coding with the actual
implementation of the spec.
• Help build the TCK; all implementations must pass the
test suite – this is a great way to gain test experience.
88

89. How to start an AdoptAJSR project
• Start here:
http://java.net/projects/adoptajsr/pages/Home#Leading_an_Ad
.
• Set up a wiki page to coordinate your activities e.g.
http://java.net/projects/ljc-london-jug/pages/JSR-310.
• Link that into the matrix at
http://java.net/projects/adoptajsr/
• Contact the Spec Lead & EG - find links on JSR pages e.g.
http://jcp.org/en/jsr/detail?id=310
• Mail your JUG members to gather interest.
• Outline what the JSR is and why the JUG should get
involved; identify areas that you want to work on;
coordinate this with the Spec Lead.
89

90. Transparency checklist for new JSRs
• Is the schedule for the JSR publicly available, current, and updated
regularly?
• Can the public read and/or write to a wiki for the JSR?
• Is there a publicly accessible discussion board for the JSR that you
read and respond to regularly?
• Have you spoken at conferences and events about the JSR recently?
• Are you using open-source processes for the development of the RI
and/or the TCK?
• What are the Terms of Use required to use the collaboration tools
you have prepared to use with the Expert Group, so that
prospective EG members can judge whether they are compatible
with the JSPA?
• Does the Community tab for my JSR have links to and information
about all public communication mechanisms and sites for the
90
development of my JSR?

91. Next steps
• Contact the Spec Leads of in-flight Active JSRs that have not
yet migrated; encourage them to migrate to JCP 2.8.
• Assist Spec Leads in the process of migrating to JCP 2.8.
• Volunteer (through the Adopt-a-JSR program’s Transparency
sub-project) to help the PMO do transparency checks on
JSRs.
91

92. Adopt-a-JSR Transparency sub-project
• Transparency sub-project of the Adopt-a-JSR program hosted
on java.net.
• JUGs or individuals do transparency checks or audits on
JSRs.
• Provide qualitative and quantitative data to the community,
Spec Leads, and the Program Office on the JSR’s compliance
with the JCP’s transparency and participation requirements.
• A matrix of results will be provided for each JSR actively
operating under JCP 2.8 and above.
92

93. Community-provided assessment
• The Transparency sub-project will host an online form for
your input in areas such as:
• The quality and utility of the public issue tracker.
• How the Spec Lead and Expert Group communicate and
interact on the JSR’s public mailing list. Are issues being
resolved and addressed?
• Whether the Expert Group represents all relevant sectors of
the Java community,
• Whether the Expert Group has published a draft of the JSR
and whether this represents a convergence of competing
implementations.
93

94. Participate in OpenJDK
• Go to http://java.net/projects/adoptopenjdk/
• Join the mailing list.
• Join the IRC channel.
• Or contact your local JUG leader.
94

95. Join the JCP
• Join the JCP program as a corporation, non-profit,or
individual.
• Free for non-profits , Java User Groups, and individuals!
• See http://jcp.org/en/participation/membership2
• Register for an account on JCP.org.
• Download, fill out, and scan, fax or mail the JSPA form to
the JCP Program Office.
95

96. Levels of participation
• Members.
• Review specs, may participate in Expert Groups, vote in
Executive Committee elections; flexible time commitment.
• Expert Group members.
• Create JSRs (write the spec); expert in field, high time
commitment, help drive the direction of the JSR; moderate time
commitment.
• Specification Leads.
• Responsible for leading the JSR & Expert Group (EG), delivery
of spec, RI & TCK; a leading expert in area of JSR;
considerable time commitment and recognition.
• Executive Committee members.
• Define JCP governance, processes, and contractual terms of
membership. Vote on JSRs at defined stages through the
process. Moderate time commitment.
96

97. What's in it for me?
• Advance your career.
• Grow your network and
reputation.
• Make new contacts.
• Improve your “soft skills.”
• Verbal and written
communications.
• Negotiation.
• Collaboration.
• Teamwork.
• Have fun!
97

98. Make the future Java!
98

99. Questions?
99