 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
Executive Committee Meeting Minutes
|
||||||||||||||||||||||||
Thursday September 10 |
Friday September 11 |
|
|
PMO |
|
|
|
ME EC |
SE/EE EC |
Total attendance: 12 |
Total attendance: 11 |
| Since 75% of the ME EC was present, that EC was quorate for
this meeting on September 10 Since 75% of the SE/EE EC was not present, that EC was inquorate for this meeting on September 10 |
|
PMO |
|
|
|
ME EC |
SE/EE EC |
Total attendance: 12 |
Total attendance: 10 |
Since 75% of the ME EC was present, that EC was
quorate
on September 11 |
|
The ECs approved minutes of the July meeting.
Patrick delivered the EC stats presentation.
Patrick reported the following personnel changes:
SE/EE
ME
Patrick reported that the following members' terms expire this year:
SE/EE EC
o Ratified seats: Fujitsu,
HP, IBM, Oracle
o Elected seat: Doug
Lea
ME EC
o Ratified seats: Motorola,
Qisda, Siemens, Vodafone
o Elected seat: Ericsson
He also reported that because of the resignations of Philips, Motorola, and Nortel, there would be three additional ratified seats to fill during this year's elections.
The ECs then went into private session, during which Patrick informed EC members of Sun's current plans for nominations to the ratified seats. EC members provided their input into this process.
Roberto presented an update on Java EE 6 (see presentation.)
Patrick asked whether the team had plans to promote Web Profiles. Roberto said
that they were still working on this, and hoped to get some books published.
Doug Lea pointed out that those who "live within the Web Profile" are
typically programming in scripting languages, and may not be writing Java.
Is this a new direction? Roberto agreed that things are changing. Werner Kyle
asked about the relationship between profiles and modularity in Java SE. Roberto
responded that more profiles are likely, and that they are looking forward to
modularization. Patrick asked whether any other profiles were currently planned
by Sun or others. Roberto said no. Patrick emphasized the importance of publicizing
this aspect of the new release, since it will help to counter the perception
that Java EE is big and monolithic.
Werner Keil presented an introduction to JSR 321: Trusted Computing API for Java. See presentation.
The discussion primarily focused on the Terms of Use for the new jcp.org website. EC members expressed concerns that the license grant for non-JCP members was too broad, and might lead to people inadvertently giving away patent rights to unrelated matters. Patrick pointed out that these terms apply only to those who haven't signed the JSPA (otherwise the JSPA applies), and that they would therefore apply only to a minority of users of the site. In email discussions after the meeting it was pointed out that this might unreasonably broaden the definition of Contribution in the JSPA. Steve Wolfe suggested narrowing the Terms of Use language to state that rights are granted only if the contribution is incorporated into a JSR. Patrick agreed to work with the JCP lawyer to draft an alternative, and to circulate this for discussion.
Roger Riggs asked whether it would be possible for contributers to withdraw a previous contribution, and Wayne Carr asked whether it might be possible to label something as "not a contribution." There was no interest in following up on either of these ideas.
Doug Lea and Josh Bloch pointed out that there are many sites other than jcp.org where Expert Groups and JCP members can collaborate, and that we should not be concerned about relatively low participation on our website.
Werner Keil gave presentation on Financial APIs for Java. He discussed the possibility of implementing such APIs on top of JSR 275: Units Specification. Members discussed whether it might be preferable to implement financial APIs as a separate JSR, but they reached no conclusions.
Following on from the discussion of JSR 275, members discussed the possibility of implementing some kind of "incubator process" to support the early development of ideas that might eventually be submitted as formal JSRs. Danny Coward suggested that potential spec leads should come and talk to the ECs, presenting their ideas and asking for feedback. Doug Lea pointed out that he had made a presentation on incubator process during the second EC meeting he attended, many years ago. He raised the possibility of IP issues that might result from such a process, but could not remember specific details. Patrick Curran wondered wether we should define a "pre-JSR" stage, before the formal submission of a JSR. Danny agreed that it might be useful to have a mechanism to explore ideas that haven't yet met the criteria to be voted on in an inception ballot. Steve Wolfe pointed out that these kinds of discussions could be carried on in the jcp.org discussion forums.
Wayne Carr pointed out that the W3C has a formal incubator process intended to address IP issues. Wayne noted there has been disagreement about it, but it would be worth looking at. Don Deutsch noted that the W3C process has had mixed success. Some of the incubator groups progressed to standardization, but there were IP issues to be resoved - members would need to know what IPR commitments they would have to make when joining a formal working group.
Patrick suggested that a more lightweight process would simply be to encourage members to discuss potential JSR ideas in the jcp.org forums, and to make more formal presentations to the EC. Roger Riggs pointed out that we expect people to socialize JSR ideas before submitting, and perhaps all we need to do is to re-emphasize this. Don Deutsch pointed out that the EC members would not necessarily be qualified to provide useful feedback. Danny Coward responded that the primary issues with JSR proposals are not usually technical, but process-oriented. Doug Lea suggested that we might hold a special face-to-face meeting at which several potential ideas could be presented and discussed.
Members agreed that at a minimum we should create a forum in which members could float JSR ideas and discuss them with others, that we should provide a dedicated discussion forum for promising ideas if their proponents requested this, and that we should encourage potential Spec Leads to present their ideas to the ECs, either by email or by making a formal presentation, so that the the ECs could provide feedback. Patrick agreed to ask the PMO to implement these suggestions, and to update the Spec Lead Guide accordingly. Members recognized that if we do encourage more early discussion and socializing of JSR ideas, one result might be that more badly-prepared JSRs would be voted down when they were actually submitted.
Members agreed to discuss this matter further at a future meeting.
Heather Vancura reported on the status of the new software that would be used in the upcoming annual elections. She explained that candidates would be expected to provide a qualification statement, a position paper, a biography, and a photograph. She then demonstrated the software.
Don Deutsch agreed to try to find space at Oracle for this meeting.
Patrick Curran summarized the work being done in the ME Working Group. He noted that the group is focusing on several areas: marketing, JATAF, security, and licensing.
John Rizzo summarized the security domain problem, pointing out that having multiple operator domains makes it very difficult for developers. Kay Glahn pointed out that MSA and MSA2 have tried to address these issues, but only as a recommendation, not a requirement. The operators are reluctant to agree to a uniform domain policy, preferring to have full control over their networks.
On licensing, Patrick explained that ME Working Group members are concerned that the difficulty of licensing ME components from multiple suppliers is an obstacle to deployment. Cuihtlauac Alvarado asked how this is addressed in Java SE and Java EE. Danny Coward pointed out that because the SE and EE platforms are more monolithic, with far fewer optional components, this is less of an issue.
Doug Lea returned to the security question, expressing concerns that we may run into similar issues in Java SE when it migrates down to small devices. Others pointed out that we haven't addressed this in Java SE, and that the difficulty in ME is a consequence of the business models of the operators, who want to retain their share of the revenue stream. Danny pointed out that the EC is unlikely to be able to exert much influence on the operators. Steve Wolfe asked whether there is something specific to Java ME that is exacerbating this problem. Others said there is not.
Doug Lea pointed out that the isolation and resource-management specs could help to address some of the security issues yet they aren't typically implemented.
Cuihtlauac Alvarado provided EC members with an introduction to the JATAF program. This is an initiative led by Vodfone, Sony Ericsson, Orange, and Sun. Others are being encouraged to join (Aplix recently joined.) The group plans to develop an open-source test suite for Java ME, hosted at java.net. The test suite will focus on test cases that demonstrate fragmentation problems.
He and John Rizzo pointed out that many developers have figured out how to write portable Java ME programs, but that they often tend to keep this information secret. The JATAF program hopes to encourage developers to share such information, and to provide them with a forum for doing so.
Doug Lea pointed out that the practice of keeping TCKs proprietary may encourage such "information hoarding."
Cuihtlauac explained that JATAF will provide a feedback loop, whereby problems can be reported back to the Spec Leads of component JSRs, and hopefully fixed in Maintenance Releases. He noted that they haven't yet recruited individual developers (though they will welcome their participation), and that they will try to recruit other carriers besides Orange and Vodafone.
Brian Deuser pointed out that the openness of the test suite is a good thing, since it will help to ensure that we have a quick turnaround and can continually incorporate new tests. Kay Glanh noted that the scope of JATAF is different from TCKs - and that JATAF tests will go beyond the pure conformance testing that is covered by the TCK.
Brian warned that JATAF tests should be voluntary rather than a formal requirement.
The meeting concluded with a private-session discussion during which membes discussed their involvement in and commitment to Java ME.
