JCP.next: reinvigorating Java standards How you can make a difference

1. Patrick Curran, JCP Chair JCP.next: reinvigorating Java standardsHowyoucan make a difference July 2013

2. Welcome!

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

4. Standards make the world go round

5. Languages & protocols

6. Interfaces

7. Specifications

8. Blueprints

9. Certification

10. No vendor lock-in

11. Industrial-strength systems

12. Java standards

13. The Java Community Process (JCP) is the open, inclusive process through which we develop and revise Java technology specifications (JSRs). The JCP program now has over 1,000 corporate and individual members. More than 350 Java technology specifications have been developed through the JCP program; ~two thirds have reached Final Release. For the community, by the community

14. Java SE

15. Java ME

16. Java EE

17. How do 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)

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

19. Organization

20. Who does what? 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.

21. The Executive Committee Executive Committee (EC) responsibilities: Review and vote on JSRs as they move through the process. Evolve organization’s Constitution. 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 face-to-face meeting each year. We have a public mailing list for feedback. Sign up at http://java.net/projects/jcp-ec/lists.

22. Executive Committee elections We used to have two Executive Committees (one for Java ME and one for Java SE & Java EE combined). JSR 355 merged them into a single Committee with 25 members. Oracle has a permanent seat. 16 seats are Ratified (Oracle nominates candidates and the entire JCP membership must approve by voting). The remaining 8 seats are Elected (any JCP member may nominate themselves and members choose by voting). Each year half of the members must stand for re-election. In 2013, in order to complete the merge into a single Committee, all existing members must stand for re-election.

23. Executive Committee members Members listed in red are new to the EC as of November 2012.

24. The Spec Lead The JCP member responsible developing a JSR. Must deliver the Spec, RI, and TCK. Oracle is the Spec Lead for the three existing Platforms: Java ME, Java SE, and Java EE.

25. The Expert Group The Expert Group is recruited and led by the Spec Lead. All members of the JCP are eligible to join. Should represent all interested sectors of the Java community. Works as a team to define the JSR and to develop the Spec. Must operate transparently, so that JCP members and the public can review and participate in its work.

26. 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: free. Commercial organizations: $5K/year.

27. 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.

28. The JSR development cycle • Includes formal public reviews and votes by the Executive Committee. • See the Process Document for the details.

29. Changing the Constitution

30. Legal framework and governance • The 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 must 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.

31. Using the Process to change the Process • We modify the Process (as defined in the JSPA and the Process Document) by filing JSRs. • The Chair is the Spec Lead and the Executive Committee members form the Expert Group for these JSRs. • Process-change JSRs go through all of the same stages as regular JSRs. • The output is a new version of the Constitution. • Since 2012 we have been working on a series of three JSRs, collectively referred to as JCP.next, to reform the our processes.

32. JCP.next.1 (JSR 348)

33. JSR 348 • JSR 348: Towards a new version of the Java Community Process was deliberately focused on relatively simple changes that we could be implemented within about six months. • It was completed in October 2011, and defined version 2.8 of the Process Document. • All complicated matters, including anything that would require changing the JSPA, were postponed until JCP.next.3. • This JSR implemented a number of relatively simple but significant changes to make our processes more transparent and to enable broader participation.

34. JCP.next.2 (JSR 355)

35. JSR 355 • Because Java is One Platform and because we expect Java ME and Java SE to converge over time, JSR 355 was introduced to merge the two Executive Committees into one. • This JSR reduced the number of EC members to 25 and kept the same ratio (2:1) of Ratified to Elected seats. • It made no other significant changes to our processes. • The JSR was completed in August 2012. • Implementation began during the October 2012 JCP elections and will complete in October 2013, during this year’s elections.

36. That was easy!

37. JCP.next.3 (JSR 358)

38. Modifying the JSPA • The JSPA has not been significantly modified since 2002. • Since then the organization and the environment in which we operate have changed significantly. • Most significantly, the widespread adoption of open-source licensing and development practices. • The document is long overdue for updating and cleanup. • However, it is very complicated and difficult to understand. • We must be very careful when making changes. • Plus…

39. Now the lawyers are involved!

40. Why it matters • The JSPA defines the way in which Intellectual Property (IP) rights are granted and the terms under which the Spec, RI, and TCK must be licensed. • We must make sure that the technologies we incorporate into Java are "safe" from an IP perspective, so that people can implement them and use them with confidence.

41. Independent Implementations • Compatibility • Licensing and open source • Transparency • Patent policy • The role of individuals • Fee structure • The role of the RI • TCK changes • Expert Group dissolution • IP flow • Withdrawal of IP • End of life for JSRs • Escrow process • Refactor the JSPA • Collaboration with other SDOs Our shopping-list See this presentation and the Issue Tracker for full details. Our efforts to date have been focused on the items listed in red.

42. Progress so far • Our initial focus has been in two areas: • IP policy, licensing, and open-source. • The role of individual members in the JCP. • Each has been driven by a Working Group. • The Working Groups meet regularly, and report back to the Executive Committee (the Expert Group for this JSR) at the monthly EC meetings. • See the public EC meeting summariesfor their latest reports.

43. JSR 358 goals • Maintain compatibility guarantees. • Embrace open-source licensing and development processes. • Simplify IP-flow and licensing models. • Enable even more openness, transparency, and participation.

44. Strong compatibility • All JSRs will be covered by a standard Spec license that includes strong compatibility requirements. • All implementations must pass the TCK.

45. Embrace open source • Reference Implementations must be developed through open-source projects and released under open-source licenses.

46. Developer access to TCKs • All TCKs must be made available under a Community TCK License to those who participate in the RI-development projects.

47. Easier membership for individuals • A new Affiliate membership class for individuals with a much simpler membership agreement. (No lawyers required!)

48. Follow us on java.net • Of course, we do all our work 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 (our meeting minutes and working documents are published here). • Let us know what you think. • Help us to do the right thing!

49. And so...

50. Putting the community back into the JCP • JSR 348 enabled you to participate in development of Java specifications. • Now we are embracing open-source development processes and licensing. • JSR 358 will enable you to participate in the implementation of these specifications. • The RIs will be available under open-source licenses. • You can access to TCKs through the Community TCK License. • It will be even easier for you to join the JCP. • There are no more barriers to participation. • If you care about the future of Java you have no excuse...