Find JSRs
Submit this Search


Ad Banner
 
 
 
 

JCP EC minutes (public): January 12-13, 2010

Executive Committee Meeting Minutes
for 12-13 January 2010

version 0.4: March 18, 2010

Date

January 12-13 , 2010

Location

Face to face meeting, hosted by Sun in Santa Clara, CA

Agenda

(PMO Presentation)

Attendance: Tuesday 12 January

PMO
  • Patrick Curran, Heather VanCura
ME EC
SE/EE EC
  • Aplix –  John Rizzo – present
  • AT&T – Roger Mahler – present
  • IBM – Mark Rogalski – present
  • Nokia – Erkki Rysa - present
  • Orange France – not present
  • RIM – James Warden – present
  • Samsung – Hobum (Vincent) Kwon - present
  • Sean Sheedy – present
  • Siemens – Chistoph Kuhmuench – present
  • SK Telecom – Dave Kim – present
  • Sony Ericsson – not present
  • Sun – Calinel Pasteanu – present
  • Time Warner Cable – not present
  • T-Mobile – Gero Schultz – present
  • Vodafone – Eden Bektesevic – present

Total attendance: 13

  • Apache – Geir Magnusson – present
  • Eclipse – Mike Milinkovich present
  • Ericsson - Jens Jensen – present
  • Fujitsu – Mike DeNicola – present
  • Google – Josh Bloch, Bob Lee – present
  • HP – Scott Jameson present
  • IBM – Mark Thomas, Steve Wolfe – present
  • Intel – Wayne Carr – present
  • Werner Keil – present
  • Doug Lea – present
  • Oracle – Don Deutsch – present
  • Tim Peierls – present
  • RedHat – Scott Stark – present
  • SAP – not present
  • Sun – Danny Coward, Roberto Chinnici – present
  • VMware (SpringSource) – Rod Johnson – present

Total attendance: 15

Since 75% of the ME EC was present, that EC was quorate for this meeting
Since 75% of the SE/EE EC was present, that EC was quorate for this meeting

Attendance: Wednesday 13 January

PMO
  • Patrick Curran
ME EC
SE/EE EC
  • Aplix –  John Rizzo – present
  • AT&T – Roger Mahler – present
  • IBM – Mark Rogalski – present
  • Nokia – not present
  • Orange France – not present
  • RIM – James Warden – present
  • Samsung – Hobum (Vincent) Kwon - present
  • Sean Sheedy – present
  • Siemens – Chistoph Kuhmuench – present
  • SK Telecom – Dave Kim – present
  • Sony Ericsson – not present
  • Sun – Calinel Pasteanu – present
  • Time Warner Cable – not present
  • T-Mobile – Gero Schultz – present
  • Vodafone – Eden Bektesevic – present

Total attendance: 12

  • Apache – Geir Magnusson – present
  • Eclipse – Mike Milinkovich present
  • Ericsson - Jens Jensen – present
  • Fujitsu – Mike DeNicola – present
  • Google – Josh Bloch – present
  • HP – Scott Jameson present
  • IBM – Mark Thomas, Steve Wolfe – present
  • Intel – Wayne Carr – present
  • Werner Keil – not present
  • Doug Lea – present
  • Oracle – Don Deutsch – present
  • Tim Peierls – present
  • RedHat – Scott Stark – present
  • SAP – not present
  • Sun – Danny Coward, Roberto Chinnici – present
  • VMware (SpringSource) – Rod Johnson – not present

Total attendance: 13

Since 75% of the ME EC was present, that EC was quorate for this meeting
Since 75% of the SE/EE EC was present, that EC was quorate for this meeting

Minutes

Minutes of previous meetings

The ECs discussed the public minutes from the previous December meeting. Don Deutsch pointed out that the ME EC was not (at the time of the discussion) quorate and that it would therefore be inappropriate to approve the minutes. After some discussion, EC members agreed that in future minutes should be reviewed, corrected (if necessary), and approved by mail rather than in EC meetings, in order to avoid this problem.

Later in the day, when the ME EC became quorate, the minutes were discussed again and were approved.

EC statistics

Patrick delivered the EC stats presentation.

Personnel changes

Patrick reported that Pardeep Khowash is the new alternate representative for AT&T.

Special election for Java ME

Year-end statistics

Patrick presented year-end statistics, discussing the number of JCP members and the election results, and providing details of active JSRs, Spec Leadership, and Expert Group membership. See the presentation for details.

During discussion, it was noted that the number of active JSRs was down slightly, but not significantly, from the previous year. It was suggested that data on "un-deployed JSRs" (JSRs that have been completed, but which are not implemented commercially) would be interesting. Also, members suggested that we investigate the "slow JSRs" further, and provide an average of the completion times. Heather reported that the PMO is in the process of reviewing recently-completed JSRs, and that the investigaions would focus particularly on cases where the JSR took an unusually long (or short) time to complete.

Patrick provided some additional historical data showing the rate of submission and completion of JSRs over time. Members pointed out that a decline in the number of new JSR submissions should not necessarily be interpreted as a problem, since as the platforms mature it would be expected that fewer new JSRs would be filed. Additional data on the number of maintenance releases would help to clarify the situation (these could be expected to increase over time.)

Inactive JSRs

Heather Vancura summarized the current situation with Inactive JSRs (see presentation) and members discussed what steps should be taken to ensure that these JSRs are either withdrawn or revitalized. EC members noted that there are a significant number of JSRs that have made no progress - often for several years - since the Expert Group was formed (or claimed to be in the process of formation), and suggested that the PMO focus on these initially, encouraging the spec leads to withdraw them.

The PMO agreed to do so, and representative from EC member companies agreed to help with JSRs whose spec leads work at their companies.

The PMO promised to report on progress at future meetings.

Agility: lessons from JSR 330

Bob Lee from Google led a discussion on JSR 330, focusing on factors that helped the Expert Group complete this JSR in record time. He emplasized the importance of working in the open (with public mailing lists and issue-tracking) and of doing all the work by email, discouraging private conversations. He pointed out that the majority of the work had been completed before the JSR was filed, noting that it might have been more difficult to handle contentious issues within the JCP process. Josh Bloch agreed, arguing that it is best to resove contentious issues before filing a JSR.

Other "best practices" include focusing on a relatively constrained area, and recruiting a highly motivated, skilful, and diplomatic Spec Lead.

Recommendations to the PMO included encouraging more transparency, and providing public issue tracking.

Heather noted that the PMO is conducting case studies in agility, and promised to report back to the ECs.

2010 meeting schedule and locations

EC members tentativly confirmed the 2010 meeting schedule, agreeing that the East Coast face-to-face meeting be held at AT&T's premises in Atlanta, Georgia, while the European meeting would be hosted by Deutsche Telekom/T-Mobile in Bonn. Members agreed to discuss by email the possibility of changing the May date to enable more members to participate.

Spec-lead discussion

Alex Buckley gave a presentation on JSR 294 and transparency. During this presentation he suggested that some kind of incubator process, mandating a formal scoping exercise before JSRs are filed, would be helpful. He suggested that the process should mandate publicly readable and writeable observer lists.

He also pointed out the importance and difficulty of engaging with "casual observers" - those who comment on a JSR in blogs or elsewhere outside of the "normal" discussion forums.

Finally, EC members discussed the importance of having a "Contribution Agreement" to ensure that those who participate in a JSR in a more casual manner (that is, not as members of the JCP) formally assert that they have the rights to the IP that they contribute, and make a formal grant of that IP. See the JSR 294 Observer license for details.

Discussion of incubator processes

Three EC members with experience of incubator processes in other standards-developing organizations provided an introduction to how these organizations implement such processes:

Don Deutsch explained the Patent Policy options that W3C incubator groups must choose from. Option one involves no licensing commitments by participants. Under option three all particpants agree to abide by the W3C Patent Policy for any work transitioned to the Recommendation Track. Option two effectively gives each participant the freedom to chose which of the other two options they will abide by.

Ten or eleven incubator groups have been formed and a small number had progressed to become formal Working Groups. The incubator groups are approximately evenly split between the first and the third patent option. Groups that were formed simply to gather data or to perform research typically chose option one, while groups that hoped to move on to develop formal specifications typically chose option three. (None chose option two.) Don noted that the W3C had underestimated how important IP issues like these would be. Patrick noted that these issues are similar to those the JCP has been grappling with around contribution agreements and Terms of Use for participation in discussion forums.

Calinel asked how successful the whole incubator process had been, and Don responded "not very." Danny asked why anyone would work through the W3C rather than simply creating their own public mailing list for discussion. Don pointed out that the W3C provided a ready world-wide audience.

Don noted that the primary reason for defining the incubator process was to permit W3C activities while limiting the expenditure of staff resources (formal Working Groups must be assigned resources). He pointed out that the JCP would not have this problem since it makes no commitment to assign staff resources to Expert Groups.

Mike Milinkovich then presented an overview of the Eclipse incubation process (see slides.) He said that the process was inspired by the Apache foundation, but differed from Apache somewhat, since for Eclipse the incubator is a state whereas for Apache it is a place. Every Eclipse project starts in the incubation state, and the development of a statement of scope is a significant aspect of the process. The incubation process is "training wheels" for an Eclipse project. Expectations are lower than for fully-mature projects, and this is an opportunity for project members to learn the process and to make mistakes. The requirement to find two "mentors" from among the Architecture Council (which has 40-50 members in all) helps to filter out impractical projects. There are few IP issues since all Eclipse projects use the same license and adopt the same IP policy.

The process of "graduation" from incubator state typically involves a formal review. Releases are now labeled 1.x, and APIs are considered permanent. Projects are now expected to have mature and development, build, and release processes. While 10-15% of projects never progress beyond the incubation state the majority do graduate, some in only a few months while others take longer.

Patrick pointed out that if the JCP had a similar incubation state this would resolve the problems with JSRs that never progress beyond the Expert Group formation stage.

Finally, Geir Magnusson provided an overview of the Apache incubator process. This was created to ensure that code donations to Apache were legaly appropriate, and to ensure that projects follow Apache processes and principles. He noted that there are many similarities to Eclipse incubators, but that at Eclipse the process is more top-down (with the Board having significant influence) whereas Apache is more bottom-up (the project has significant autonomy.) As with Eclipse, the primary purpose is to ensure that the project is ready to take off, and as with both Eclipse and W3C, patent grants are covered by the incubator process.

Members then discussed the implications of an incubator process for the JCP. It was pointed out that the JCP's lack of a standard licensing model might pose difficulties since uncertainty about the eventual licensing model might deter people from participating in an incubator project.

John Rizzo asked whether incubation was just another stage at the beginning of the process. Mike DeNicola pointed out that mentoring was an essential component of the Eclipse and Apache incubation processes. Steve Wolfe noted that many Spec Leads expect to make commercial gains from their activity. It was therefore suggested that incubator processes might apply only to Open Source projects.

Danny Coward pointed out that an incubator process might increase the chances of an Expert Group succeeding, and would eliminate the "surprise factor" as EC members have only a two-week period to decide whether to support new JSRs.

Wayne Carr noted the "Gold Rush problem," whereby those  who stake a claim to "territory" by filing a JSR are then considered to own that territory.

John Rizzo argued that if an incubator process is introduced it should not require an additional vote.

Josh Bloch asked whether we should allow multiple incubator projects in the same space. Geir Magnusson said yes - we want the best technology, not the first to be proposed.

Scott Stark argued that any discussion of incubators is premature, and that the larger JCP process issues should be resolved first.

[The EC adjourned for the day, but agreed to pick up the discussion the following morning. The notes below are from the next day's discussion.]

The follow-on discussion quickly moved on from incubators to a broader discussion of licensing issues. John Rizzo argued that a complete overhaul of processes and licensing models was needed. Ideally, a unified licensing model would be introduced. Josh Bloch argued for a permissive BSD-like license. Others argued that this would not ensure that people who make changes to a technology would give them back to the community, as the GPL requires.

Wayne Carr and others pointed out to new members that the EC has had extensive discussions about similar licensing suggestions in the past (with particularly important resolutions passed at the "meeting in the barn" in December 2007). They noted that much of the investigation being proposed had already been done and probably didn't need to be repeated. With the Oracle acquisition pending and expected to be determined one way or the other shortly, it was decided to postpone the discussion.

Tim Peierls suggested that the EC present Oracle with an explanation of the changes they would like to see in the organization. There was no consensus to do so, but after the meeting Wayne Carr circulated by email a summary of previous discussions.

Review of the Sun/Apache situation

The meeting went into private session to provide a review of the history of the Sun/Apache situation for the benefit of new members.

JSR 275 Presentation

Werner Keil gave a presentation on JSR 275. Members expressed a variety of concerns about the design approach taken by the Expert Group, including naming issues and a possible overlap with JSR 310: Date and Time APIs. (JSR 275's Public Review Ballot was scheduled for the week after this EC meeting. In that ballot many EC members expressed their concerns by voting "no" and the ballot failed. See the results for details.)

MIDP3 presentation and demo

Paul Su from Aplix gave a technical overview of MIDP 3, followed by a demonstration. See the presentation for details.

ME Working Group status

Sean Sheedy gave a brief status report from the ME Working Group. It was decided that the next meeting would be in two weeks.

Modularity and profiles

Patrick introduced this discussion by pointing out that there are increasing calls for a merge of Java ME and SE, that modularity is being introduced in Java SE, and that profiles have been introduced in Java EE. What are the implications of these trends for the work of the JCP, and for the broader issues of compatibility?

Doug Lea pointed out that it is often difficult for technologies to "piggy back" on top of the core. Different rules are required for the base. Dependency management, and new testing strategies are required. Patrick responded that the Java EE CTS is being modularized into component TCKs.

Roberto said that Java EE is taking things slowly, and so far has introduced only one profile.

Alex Buckley noted that the JDK is being  physically broken into smaller pieces, but unless a module system is actively invoked the user of the system will see no difference (the platform will still be "complete.")

Patrick argued that once modularization is enabled, subsetting is inevitable. Tim Peierls noted that the RESTlet community has a common code base but builds for multiple environments (Java SE, Java EE, Android, Google GWT, etc.)

Patrick asked whether modularity might result in fragmentation. John Rizzo argued that this is not inevitable. In the ME space the problem is not the existence of "modules" but rather incompatibilities in implementations - optionality is beneficial. Danny noted that we have significant "fragmentation" between Java SE and Java ME (ME is a subset of an early version of SE, and the two have since diverged.) The API, and language subset in Java ME should be consistent with Java SE. Wayne Carr pointed out  that it is difficult to create optional specifications that run on both platforms.

Patrick argued that optionality endangers interoperability.

Alex Buckley pointed out that if so, this is a failure of dependency management. In a well-designed system requirements are documented and missing components would be downloaded (or could be manually installed.) Steve Wolfe asked whether JSR 294 implements such a dependency-management system. Alex responded no - it enables such a system, but the Expert Group did not want to "tread on the toes" of any individual module system. Steve asked about the dangers of incompatibilities between the behavior of modules as the interact with different environments. Alex responded that this can be handled by versioning on top of dependencies. Compatibility is well understood.

Wayne pointed out that modularization doesn't necessarily mean a free-for-all. Profiles will be defined. Josh argued that making the compatibility tests freely available would help.

Steve Wolfe asked who defines modules? John Rizzo responded that in Java ME individual JSRs define modules, and then there are "umbrella JSRs" that define stacks (profiles.) He noted that for Java ME the issue of royalties owed per JSR was an obstacle to the implementation of a real module/dependency-management system. Scott Stark pointed out that this is soluble. A factory method could be designed to fail if the appropriate license was not present.

Steve Wolfe asked who decides the level of granularity with which APIs are exposed and modules defined. Don Deutsch asked whether the platform-subset issue is confined to Java ME and Java SE. Danny responded "no", since Java EE depends on the entire Java SE platform. Roberto noted that Java EE might prefer a smaller base, and he noted that the influence is two-way, since Java EE specifies requirements for Java SE.

Doug, Patrick, and Scott argued that dependency management is a good thing, that TCKs must be aware of dependencies, and that specs should explicitly call out dependencies.

Adjourn

After thanking Sun and Heather Vancura of the PMO for hosting and arranging the meeting, the ECs adjourned.