 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
Executive Committee Meeting Minutes
|
| Thursday September 25 |
PMO |
|
Executive Committee |
Total attendance: 23 of 24 voting members |
| Since 75% of the EC's 24 voting members were present, the EC was quorate for this session |
| Friday September 26 |
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 for this session |
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):
SAP will regain their voting privileges at the end of this meeting.
See the Action Item tracking file.
Heather presented the usual EC Stats. Patrick congratulated the EC on the perfect voting record on several recent EC ballots (all eligible members voted). Heather then reported for the first time on compatible implementations of several JSRs. (This is a new requirement under JCP 2.8.)
Gil Tene suggested that it might be useful to add a note on jcp.org asking people to volunteer information about compatible implementations. Ben Evans noted that the London Java Community has a mechanism permitting the developers of libraries to test whether they are compatible with Java SE 8. Patrick pointed out that this is a different form of compatibility - the PMO will report on implementations of JSRs that have verified by running the TCK that they are compatible. Gil pointed out that Docker has published an "official" release of Java SE 8 that is based on the unrealized Java SE update 40. Patrick responded that such a release is by definition incompatible.
Heather presented a report from the PMO (see the presentation for details). She summarized the JCP's plans for JavaOne, and then outlined the schedule for the annual elections. [Later in the meeting Steve Harris announced that CloudBees, who hold an elected seat through 2015, plans to resign their seat as of the 2014 elections due to a change in the company's business strategy. This timing will permit the election for their seat to be rolled into the October elections rather than requiring a separate Special Election. After the meeting Patrick reported to the EC via email that very few candidates had nominated themselves for elected seats. He therefore suggested, and the EC agreed, that the nomination period should be extended by a week until October 6.]
Heather then went on to discuss the PMO's efforts to clean up the membership database and to ensure that we have current contact information for all members. In the process we have canceled many memberships where the company or individual no longer wished to (or perhaps was no longer eligible to) participate, or where we were unable to contact the member.
As a result of this cleanup (which is almost complete) the current membership numbers are:
She reported that the decision to waive membership fees for corporations has resulted in us signing up 10 new corporate members in the last few months.
Patrick noted that we expect significant membership changes as a result of JSR 364. The new Affiliate membership class should enable us to recruit many more individual developers while the elimination of fees for corporations presents an opportunity to stage a recruitment campaign to increase the number of corporate members.
The EC then moved on to a general discussion of how we might recruit more corporate members.
Gil Tene argued that we should actively recruit employed individual members since they are likely to encourage their employers to join.
It was suggested that the new emphasis on the Internet of Things (IoT) might present the opportunity to recruit in new areas and market segments (for example in the automotive business). Some members expressed concern that they didn't see a lot of progress in IoT. Calinel Pasteanu responded that much was happening. Patrick suggested that Calinel should deliver an update at a future EC meeting. (An AI has been recorded to capture this.) It was also suggested that we might target developing economies.
Patrick pointed out that we have EC representatives from Brazil and Egypt, and asked them for their perspective.
Leonardo Lima said that his company had historically borrowed or consumed technologies rather than participated in their development. They chose to participate in the JCP in order to gain insight into new developments. In particular, they are dependent on IoT technologies and wanted to help standardize these (they are too proprietary at the moment).
David Britto said that in the 1990s web technologies emerged. At the time people didn't know how they would develop but Java emerged with its promise of Write Once Run Anywhere and became successful. Java has a similar opportunity in the IoT space (it can solve problems) but it's not yet clear whether it will succeed.
Mohamed Taman said that in the future developers will need IoT skills just as they now need mobile skills.
Heather suggested that we should start by contacting our previous corporate members and encouraging them to re-join. Donald Raab suggested that targeting developers can help. Heather noted that individual members are sometimes reluctant to ask their employers to join.
Ben Evans suggested that Spec Leads could provide us with lists of companies to target. Heather responded that Ed Burns has helped in this area with JSF.
Mike Milinkovich and Mike DeNicola both pointed out that we need Business Development people to actively recruit corporate members. Oracle's Java Evangelists and possibly also the Java sales team should be promoting the JCP. Heather responded that the evangelists already do. Patrick agreed that it would be helpful if we developed some slides and materials that others could use in these efforts. (Patrick had earlier presented some slides he had used during a recent corporate visit in China.) Bruno Souza noted that JUGs could be a significant help in this area.
Patrick agreed to initiate further discussion on this subject via email. (An AI has been opened to track this.)
James Hunt (Spec Lead for JSR 282) reported on his plans for an update to this JSR (see the presentation for details).
Patrick asked why such slow progress has been made on this JSR since it was first approved in 2005. James responded that real progress was made between 2005 and 2009 when an Early Draft Review was published. However, he noted that progress was necessarily slow, since this is a very complex specification that has great impact on the VM. The EDR was of high quality. In 2009 the TimeSys Spec Lead left the company, and since then the Spec Lead role (and ownership of the relevant IP) has been transferred to Aicas GmbH.
Werner Keil asked whether portions of the spec are optional. James responded that some features are optional, but that the VM can be queried programatically to determine what features are available.
Patrick suggested that the EG use the Adopt-a-JSR program to request assistance from the Java User Group community.
James reported that given the convergence between Java ME and Java SE, the EG may refocus on Java SE. Gil Tene warned against breaking existing functionality. James noted that the TCK currently runs on Java ME. Patrick responded that if both platforms are targeted they might need to develop a separate TCK for each.
Gile Tene asked how people will know what code will execute with the guaranteed realtime functionality and what will not. James responded that scheduling guarantees will always work, but that if libraries have unbounded execution times then there are no guarantees. Gil reiterated that there are probably some existing libraries that will execute with full realtime functionality and others that will not - how will the programmer know? He asked whether the TCK verifies that code executes correctly in order to meet the scheduling requirements. James responded that it does. Gil responded "that's good - most TCKs don't provide this kind of functionality". James reported that the TCK contains two parts: one testing functionality, and one testing realtime execution capabilities.
Scott Jameson asked what was the rationale for creating a Contributor Agreement. James: "so we can accept contributions from others." Scott: "are you expecting any?" James: "we're not sure."
Anatole Tresch presented a proposal for a new Configuration JSR for Java SE (also see his presentation). Patrick pointed out that the list of supporters and proposed Expert Group members was almost all individuals. He expressed concern about this, noting that very few JSRs succeed without corporate support and participation. Ben Evans pointed out that they seem to have no vendor support at all.
Patrick asked whether there would be any conflict or overlap with the potential new Java EE configuration JSR. Anatole responded that he did not expect any conflict. The SE JSR would be more low-level, while the EE JSR would focus more on configuration for deployment. Since the Java EE JSR intended to take an SPI-based approach the two JSRs could work together; the Java EE JSR could build on the Java SE JSR.
Ben Evans warned against potential overlap, and argued that the JSR needed to have clear boundaries. He went on to point out that JSR approval is a "black and white" matter (there is an up or down vote). He suggested that it might be better to create an open-source project to guage community interest and to explore possibilities. The JSR could be filed later.
Patrick asked EC members whether they would support this JSR if it was filed.
Ben argued that the term "configuration" seemed to be a misnomer. He said that introspection seemed to be missing, but that this would be an essential feature for debugging. Anatole responded that they intended to include this feature.
Leonardo Lima noted that Java SE8 includes a minimal configuration capability and asked whether there was any intention to also support Java ME since the two platforms are converging. Anatole responded that they hadn't planned to do so, but it would be possible. Patrick reiterated the importance of support for both platforms.
Steve Harris pointed out that if they couldn't get Oracle's support then it would be unlikely that the JSR would be adopted.
Werner Keil pointed out that Java ME, Java EE, and OpenJDK have different/competing JSON APIs, and that JCache had defined its own configuration mechanism. A reusable standard is certainly required.
Patrick asked again: would any EC members vote "no" if this JSR was proposed now? Ben Evans responded that the London Java Community would - they would recommend an OpenJDK project instead. Gil Tene agreed, pointing out the importance of getting the support and attention necessary for inclusion in the platform. He added that if the JSR had a wider set of vendors supporting it then he wouldn't necessarily make that suggestion.
Alex Snaps said that he had looked at Anatole's list of configuration projects and pointed out that this seems to be a very complex area (noting that JCache has complex requirements). He expressed doubts that the proposed JSR could cover everything.
Mike Milinkovich pointed out that this would be an excellent opportunity for Oracle to support an initiative led by someone else. Patrick asked Anatole whether he had asked Oracle to support an application-level configuration JSR. Anatole said that he had had some discussions with Bill Shannon. Patrick advised Anatole to talk to the Java SE team and to OpenJDK before filing the JSR.
Bruno Souza suggested asking the existing open-source confguration projects to join. Anatole said that he is already talking to them, and expects to have further discussions at JavaOne. Heather pointed out that those are Java EE projects, and emphasized the importance of talking to Java SE and Java ME people too.
Patrick thanked Anatole for presenting and wished him luck with the JSR.
The EC then moved on to a brief discussion of the two Spec Lead presentations in the light of two open AIs:
The Configuration JSR discussion demonstrated the value of implementing this proposal. EC members did not feel it would be necessary at this time to assign a mentor to Anatole, but Scott Jameson suggested that the JSR submission template question asking which platform is being targeted should be modified to ask why multiple platforms are not being targeted. A new AI has been opened to track this.
The JSR 282 discussion was a response to this AI, and hopefully will ensure "no surprises" when the Expert Group next submits a draft for review. Scott Jameson warned against "licensing shock" and suggested that James be given feedback on the direction that our JSR 358 licensing discussions are taking. An AI has been opened for the PMO to discuss licensing with James in the context of their adoption of JCP 2.9.
Patrick reported that Oracle Legal has been asked to provide drafts of the Partner Membership Agreement, Affiliate Membership Agreement, and Employer Contribution Agreement. He explained that because these are still being discussed internally the drafts cannot be published, but he did provide a high level overview of the current state (see the presentation for details). He also warned EC members that after Legal has finished drafting the documents the internal approval process might prove to be quite lengthy.
Based on his report, the EC raised no concerns about the Afflilate Membership Areement or the Employer Contribution Agreement. (They also reluctantly agreed to accept Legal's proposal that we drop the option for employers to explicitly list the JSRs to which they were willing to permit their employees to contribute - policing this will be up to them and not to the PMO.) They provided some suggestions to Patrick for how to negotiate the contents of the Partner Membership Agreement, which is still under discussion.
Patrick summarized the current state of discussions around RI licensing. He noted that EC members have criticized Oracle's proposal to accept RIs licensed under MIT and BSD into the platform on the grounds that the additional requirement that the Spec Lead verify that contributors have signed either the JSPA or the new Affiliate Membership agreement is unreasonable and unnecessary.
Gil Tene said that we have always required the supplemental rights that are granted through the JSPA, emphasizing that we need full rights and also compatibility enforcement.
Mike Milinkovich noted that 18 months ago Oracle's proposal was that all contributors to JSRs would be required to sign the OCA. We have now come full circle to a proposal where projects would have to be under MIT/BSD/UPL, plus having all contributors sign some membership agreement, which would be unacceptable to any independent open source community. Perhaps the time has come to give up and admit that there will be no path by which innovations in the Java ecosystem can become part of the platform.
Mike DeNicola expressed concern with Oracle Legal's lack of flexibility, and suggested that it might be time to give up on this JSR. Patrick responded that he and Don Deutsch had discussed the possibility of such a stalemate several time, and that he (Patrick) had expressed the opinion that reverting to the status quo would result in a continued (perhaps accelerated) decline in JCP participation and relevance. Mike Milinkovich pointed out that since Oracle has recently introduced a ban on accepting Apache-licensed code into the platform giving up on this JSR would not be a reversion to the status quo, but actually a significant step backwards.
Steve Wolfe said he believed it was unlikely that IBM would support the current Oracle proposal.
Scott Stark suggested that if we fail to complete this JSR the result might be a schism within the EC rather than a gradual decline. He and others pointed out that significant innovation happens outside of the JCP, and it must be possible to incorporate it into the platform.
Patrick responded that he and Don would continue to discuss the matter within Oracle. He suggested that there would be no point in holding additional Working Group meetings until something changes.
Chris Aniszczyk presented an overview of how Java is used within Twitter (see the presentation for details). He reported that after adopting the JVM they saw a ten to twelve-times performance improvement. He explained that although they have their own fork of OpenJDK they have not yet contributed back. Patrick encouraged them to do so. Chris explained that in collaboration with Google they had recently launched an organization called TODO to promote best-practices in open-source development.
Bruno Souza gave an informal presentation on the role and importance of Java User Groups within the JCP. He discussed what JUGs are already doing to promote the JCP, and emphasized the importance of establishing good relationship with the JUGs to increase their level of engagement and bring results for the JCP.
He said that the JUGs' Sunday activities for JavaOne are becoming very successful; more than 400 attendees have registered for these events. The JUGs have spent a lot of time and effort over many years to make this Community Day successful, and the JCP is benefiting directly from this effort by holding the Public EC Meeting in this space. [That meeting was indeed very well attended on the following Sunday.]
Bruno showed a number of websites to illustrate the dynamism of the Java User Group community:
In the discussion that followed we agreed that we should challenge the JUGs to help us to recruit corporate members into the JCP. An AI has been opened to track this.
