 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
Executive Committee Meeting Minutes
|
PMO |
|
Executive Committee |
Total attendance: 22 of 24 voting members |
| Since 75% of the EC's 24 voting members were present, the EC was quorate on this day |
The EC Standing Rules state the following penalties for non-attendance at EC meetings (note that those who participate in face-to-face meetings by phone are officially counted as absent):
There were no changes in status as a result of this meeting. However, we noted that SAP will forfeit their seat if they miss next month's meeting. The PMO will contact them to warn them about this. (An AI has been opened to track this.)
See the Action Item tracking file.
Heather presented the usual EC stats.
Heather reported on the activities of the Individuals Working Group since the last EC meeting (see the presentation for details). She reported that we are almost ready to submit a draft of the Process Document for Early Draft Review.
Patrick led members in a review of the latest draft of the Process Document (version 4), pointing out and explaining the various changes (also see the Change log).
Werner Keil pointed out that because the EC is "one organization, one representative", we ought to prohibit a Partner Member who is employed by a company that is also represented on the EC from taking an additional (second) seat. Patrick agreed to make the appropriate change to the Process Document draft.
Patrick asked whether, as suggested in Issue #48, Community seats should be up for election each year, rather than every two years as with other seats. Members agreed that Community seats should operate the same as others, and run for two years. The Process Document draft and the Issue have been updated appropriately.
Members agreed that the document was ready for Early Draft Review. Patrick promised to make some final changes and to submit it to the PMO for posting. He encouraged EC members to read the document carefully during the review period.
Donald Smith and Mark Reinhold from Oracle presented a proposal for application-specific ("stripped") implementations (see the presentation for details). A lively discussion followed.
Steve Wolfe asked Donald to confirm that all those who create stripped implementations must have direct contractual relationships with the Spec Lead. Donald confirmed this. Steve suggested that this would cause problems (for example because it might require the disclosure of customer lists). He suggested that an alternative enforcement mechanism be found. Donald responded that the actual implementation of the relationship is still under discussion - it might require no more than a click-through.
Greg Hemstreet asked whether "end users" would need a special license agreement for a device such as a toaster. Donald responded that in these cases the manufacturer of the toaster (or perhaps the supplier of the embedded application) would be responsible for doing the stripping, and therefore for obtaining the appropriate license. Greg responded that the right to distribute should be assignable to others (distributors, for example). Donald agreed.
Steve Harris asked whether there was concern about fragmentation - with multiple "default" stripped implementations being created. Donald responded that he didn't think this would be an issue since by definition these implementations are "closed".
Members asked how a combination of an application and an implementation might be "closed" in practice. Calinel Pasteanu provided several examples from the embedded device space. Members, however, suggested that this might not be so simple in a desktop or server environment.
Werner Keil asked to what extent should all APIs, as opposed to only Java APIs, be hidden. Would it be permitted, for example for a toaster to "tweet" that the toast is ready? Donald responded that there was no intent to prohibit this kind of functionality.
Steve Harris asked whether there would be a charge for the right to create stripped implementations. Donald replied that he didn't expect so. Steve then asked whether this new model might replace profiles in Java EE. Donald said he didn't think so - the Oracle EE team were interested in this as an alternative.
Greg Hemstreet noted that in the small device market every implementation will be stripped due to device constraints. It would be difficult for device vendors to comply with the "paperwork".
Scott Stark asked about the relationship to the modularity JSR. Mark Reinhold responded that although modularity might make application-specific implementations easier to create the two mechanisms are largely orthogonal.
Scott asked what discovery mechanisms would be possible on stripped implementations. Mark responded that since the implementations are closed none would be needed. Greg noted that in the case of a power meter it might be necessary to "apply" pricing information by downloading, which might violate the rule that implementations must be closed. Donald responded that his perspective was initially focused primarily on Java SE. He promised to consult with Oracle's Java ME team to get their perspective. He suggested that he come back to the EC with an update after having discussions with the platform Spec Leads.
Scott Jameson
cautioned that the proposal is not ready for implementation, and that further discussion is needed. Patrick encouraged Donald to come back to the EC for more discussion at a future meeting.
Patrick briefly reported on the current status of JSR 358 (see the presentation for details). He invited members to attend the IP Working Group meeting scheduled for Friday July 11. Scott Jameson asked about the status of promised deliverables from Jim Wright. Patrick responded that he and Don Deutsch would be meeting with Jim and Oracle Legal later in the day, and would remind Jim that EC members are expecting to receive a written response to their concerns about the UPL and a written explanation of why Oracle is unwilling to incorporate Apache-licensed RIs into the Java platform. (An AI has been opened to track this.)
Heather provided an update on planned JavaOne activities. (See the PMO presentation for details.)
