• JSRs by Platform
• JSRs by Technology
• JSRs by Stage
• JSRs by Committee
• List of All JSRs



Register for Site

Use of JCP site is subject to the JCP Terms of Use and the Oracle Privacy Policy


• About JCP
  • Program Overview
  • JCP Process Document
  • Calendar
  • JCP Members
  • Executive Committee
  • Elections
• Get Involved
  • Overview
  • Becoming a JCP Member
  • Java in Education
• Community Resources
  • Overview
  • Tutorials
  • JCP Podcasts
  • Spec Lead Guide
  • TCK Tool & Info
  • License Reference
• Community News
  • News
  • Programs & Awards
  • Press Releases
  • Success Stories
• FAQ
• Contact Us

JCP.next Working Group Meeting
December 16 2010

Date & Time

December 16 , 2010, 8:00 am - 10:00 am Pacific time

Location

Teleconference

Agenda

• Meeting logistics
• Transparency plan
• JSR logistics
• List of items to work on (see the latest jcp.next presentation for a starting point.)
  • Additional items
• JSR timeline

Membership

The following EC members had previously volunteered to join the Working Group.

• Michael Bechauf (SAP)
  
• John Rizzo (Aplix)
  
• Scott Jameson (HP)
• Edin Bektesevic
• Stefano Andreani
  
• Steve Wolfe (IBM)
• Mark Little (RedHat)
• Mike DeNicola (Fujitsu)
• James Warden (RIM)
• Roger Mahler (AT&T)

Attendance

The following members attended this meeting of the WG.

• Patrick Curran
  
• Harold Ogle
• John Rizzo
• Steve Wolfe
  
• Edin Bektesevic
• Heather VanCura
• Mike DeNicola

Minutes

Meeting logistics

We agreed to start by meeting weekly, for an hour. We may reduce the frequency if attendance is too low. We'll hold our next meeting during the first week in January.

We recognized that work would need to be carried on between meetings - people would be given "assignments" and would be asked to report back.

We agreed to meet face-to-face after each of the EC f2f meetings. We discussed the possibility of additional face-to-face meetings of the WG. Patrick agreed to hold a Doodle poll to figure out whether, when, and where we could meet in March.

Patrick noted that we will need legal advice for at least some of our work. He had asked Oracle's lawyer to join the group but was told that this wouldn't be possible until permission had been obtained from the lawyers of all other EC members. (This is an ethical issue - an Oracle attorney cannot represent or provide advice to others without the consent of their attorneys.) We discussed possible ways to work around this (perhaps hiring an independent counsel.) We agreed that in practice we will work the business issues and then everyone will pass this off for their own lawyers to review.

NOTE: after the meeting Patrick had additional discussions with Oracle's lawyers. Hiring independent counsel really isn't practical, so before the Oracle lawyer can participate we really will need to talk to everyone else's lawyer. He will follow up by email. (In the meantime, we can certainly continue to work.)

Transparency plan

We need to provide a Transparency Plan with the JSR submission, to explain how we will involve the community, and allow them to see and comment on our work. Patrick explained that he wanted to use the infrastructure provided by jcp.org (the aliases, bulletin boards, etc.) for this purpose in order to gain some practical experience of how well this serves the needs of Spec Leads.

The process is started by filing a JSR. Once the JSR is posted a Click here to join this Expert Group link is created on the JSR's main page on jcp.org. Members of the Working Group (and other EC members who want to closely watch what we do) will need to register as members of the "Expert Group" through this mechanism. (Because the true Expert Group is composed of the entire membership of the ECs we will modify the text on the JSR's page to explain the situation.

Three email aliases will then be automatically generated:

• jsr-xxx-eg - a private alias for the Expert Group with an associated private bulletin board
• jsr-xxx-observer - an alias and associated bulletin board; anyone who registered on jcp.org can request to be subscribed to the alias and when subscribed will have write-access
• jsr-xxx-public - a public bulletin board to which messages can be mailed, but that lacks a two-way email gateway

After some discussion we decided to use the jsr-xxx-eg alias for administrative and (very occasional) private discussions and the jsr-xxx-observer alias for everything else. This will mean that anyone who wishes to will be able to read about and comment on our work. Until these aliases are created Patrick will circulate minutes and materials to the entire EC alias. Anything circulated in this manner will later be archived on jcp.org.

In addition, we will use either the file-upload mechanisms provided by jcp.org (there are two: one that's private to EG members and one that's visible to the public) or preferably a Wiki to publish documents and works in progress. (We can't use a Wiki until some configuration changes are made to prevent random visitors to jcp.org - those who aren't registered - from spamming us by writing to the Wiki. These changes are in the PMO's queue.)

Finally, we will request that the PMO set us up with a Bugzilla instance that we can use to formally log comments on our documents.

These transparency proposals (and indeed all decisions made at this WG meeting) should be approved by the full EC at its next meeting.

JSR logistics

Patrick explained that it would be logistically easier to withdraw JSR 306 (the last JCP process JSR) than to modify it, because of the changes in EC membership that have taken place since it was filed. He promised to "recycle" any useful material that was developed while that JSR was active. The plan is to file two new JSRs that will be worked on simultaneously. The first will focus on "low-hanging fruit" (changes that can be made relatively easily.) In practice this probably excludes anything that would require changing the JSPA. The second JSR will tackle more complex issues, including JSR changes.

In later discussion between Patrick and members of the PMO it was pointed out that because we encourage existing members to "upgrade" to a new version of the JSPA (we cannot force them to) it would be impractical to make two revisions in a short period of time. Therefore JCP.next will necessarily have to be restricted to Process Document changes while JCP.next++ will introduce JSPA changes as well as Process Document changes.

We decided that Oracle needs to be represented on the Working Group so that members of the PMO or the Chair are not put in the difficult position of speaking for Oracle's business interests. (We recognized that Oracle will have a significant say in the kind of changes we introduce.) Patrick promised to speak to Don Deutsch about this.

Additional items for the todo list

In addition to the items in the JCP.next presentation the following items have been suggested for inclusion on our todo list:

• Anything from JSR 306 that still seems applicable and interesting.
• Require that when the license terms associated with a JSR are significantly changed from the previous release, this is explicitly called out.
• Address the ballot-stuffing issue that was discussed at the December EC meeting.
• Decide whether the changes introduced in JCP.next should be applied to other JSRs that are "in flight."
  
  • We probably can't require that an existing JSR be ruled by new version of the JSPA.
  • We should require that the new version of the Process Document applies to all existing JSRs when they have a "state change" (including a Maintenance Review.)
    
• Minor clarifications of the Process Document.
  • Wayne Carr from Intel has documented a series of clarifications. Patrick promised to publish them for review.
• Clarification of the JSPA as discussed within the EC.
• Clarify the requirement to disclose licenses, particularly if different licenses are available for various types of implementation or different fields of use.
• Clarify what we mean by FRAND.

JSR timeline

We will aim to complete the first JSR by July 2011 and the second by early 2012.