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: 20 of 23 voting members
|
Since 75% of the EC's voting members were present, the EC was quorate for this meeting. |
PMO |
|
Executive Committee |
Total attendance: 20 of 23 voting members
|
Since 75% of the EC's voting members were present, the EC was quorate for this meeting. |
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 voting status as a result of this meeting.
Scott James will no longer represent Credit Suisse as an alternate. A new alternate has not yet been assigned.
Heather presented the usual EC stats (see the presentation for details).
Mike Milinkovich suggested the topic of the JSR 376 and JSR 379 Public Review ballots. Steve Wallin stated that the IBM representative on the Expert Group says it's not ready and that is why they voted no. He believes that the changes over the last week have been healthy, positive changes around technical merits of the JSR. He further stated that this is a sign of a positive ecosystem that the EC does not vote Yes on everything. Scott Stark stated that Mark Reinhold's response referred to a personal vendetta, but he believes that Red Hat and IBM has not been silent in the JSR Expert Group discussions, and that Java EE has not been addressed - there is a disconnect and need more time. Jackie Haynes asked what would be accomplished by delaying the release. Tim Ellison said that he is on the Expert Group and the difference of opinion is not as broad as is being portrayed and that the EC should not deep dive into technical issues. Mike Milinkovich stated that OSGi is important to Eclipse and a key role of the JCP is to have specs that enable independent implementations, Java 9 at this point is insufficient to create an Eclipse compiler. Steve Wallin said he believes that in a couple of weeks the issues can be sorted. Anish Karmarkar stated that the issues with Java Linker (jlink) are being fixed, to accommodate concerns around licensing and conformance - a jlink version of Java 9 can still be classified as a full implementation and not a sub-set. In addition, the maven module names issue is also being addressed.
Milinkovich asked about the procedural next steps following a Public Review ballot, whether the ballot was rejected or approved at this point. Heather VanCura explained the process of a reconsideration ballot if the ballot is not approved, and the next step of Proposed Final Draft following an approved Public Review ballot, and the Final Approval Ballot and subsequent Final Release, once a Final Approval Ballot is approved. Should the Final Approval Ballot not be approved, the Reconsideration Ballot would apply at that point in the process as well. Chris Dennis pointed out that the media will portray a rejection on the Public Review ballot is the end of the world but in reality it says that the EC believes that the JSR is not ready.
Simon Ritter stated that if the Public Review is approved, the EC still has the vote on the Final Approval Ballot. Bruno Souza commented that a No vote on the Public Review Ballot is probably better that at Final Approval Ballot, and that we should allow the process to work. Mike DeNicola commented that in the past there have been Yes votes with a condition that comments should be addressed at the next phase, and will vote No if the comments are not addressed in future. David Blevins stated that if the Public Review Ballot is approved now we eliminate potential to ensure comments are addressed before Final Approval Ballot. He also referenced the CDI JSR in Java EE 6, as an example of allowing extra time to allow the Expert Group to have discussion. Mike Milinkovich stated that he trusted Mark Reinhold's and to characterize a No vote as trust issue is wrong, it is not a lack of faith and trust.
Heather presented the results of the 2017 JCP EC Special Election (see the PMO presentation for details).
Heather presented migration plans for the JSR projects on java.net, including the JCP.Next JSRs, the JCP Program Office and the EC projects (see the PMO presentation for details).
Heather presented possible dates for the 2018 JCP EC Meeting calendar (see the PMO presentation for details) and asked for potential sponsor locations for the three face to face meetings. Heather will start doodle polls for the suggested locations.
Scott Stark gave an update on the Eclipse Foundation MicroProfile project (see the presentation for details). Anish Karmarkar asked whether the project would come to the JCP. Scott responded that it was not mature enough yet. Werner Keil asked about support for JSR 375, Java EE Security API support. Scott responded they will see where it goes.
Bruno Souza and Otavio Santana presented an update on their Java User Group USA tour (see the presentation for details).
Ed Burns gave a status update on JSR 369 (see the presentation for details).
Leonardo Lima gave an interesting presentation and demonstration on the use of Java at V2COM (see the presentation for details).
Gunnar Morling gave a status update on JSR 380 (see the presentation for details).
Heather summarized the status of the OpenJDK Working Group. The group has met two times and there were two open items to follow up on with status updates as well as continue the discussion about how the JCP and OpenJDK can improve coordination. Heather invited Brian Goetz to comment on the progress of the Working Group in addressing EC member concerns. Brian commented that the goal is to be faster in order to compete with other technologies; it is an advantage to them if we are slower. We need to maintain quality and specifications; the specifications are the crown jewel of Java, they are better than any other platform - we don't want to undermine them. Brian provided a "demo" of what an EDR spec bundle would look like, rolling up spec contributions from multiple active JEPs. The demo was produced manually, but this would eventually become an OpenJDK build artifact under the JCP EDR license. The proposal would be to produce a spec artifact with a JCP-friendly license including a spec bundle of all active JEPs for future Java SE Platform JSRs. These would be a single source of truth and would be posted automatically for JSR milestones. Volker Simonis inquired about what is implementation and what is specification - not every JEP goes into the platform. Some things in the JEP are not in the specification. Brian responded that only spec relevant material will go into the bundle, with all of the relevant materials incorporated as soon as available. Mike Milinkovich commented that there will always be a different perspective between EC Members are what constitutes the specification versus the implementation. Simon Ritter asked about the copyright notice on the example, noting that IBM and Azul want independent implementations. Brian responded that the EDR license will be used, which grants rights to use the specification. The spec and the code will be developed in parallel and the TCK development will also move away from the waterfall method, noting that the TCK team has been willing to start development prior to finalization of the specification. This will increase speed to release and takes away some friction - it is big opportunity for improvements. Brian added that this enabled the conformance testing process to more effectively feed back information that can be used to improve the design. By co-locating spec, RI, and TCK development in a single open repository, friction is removed from the system, which will enable us to move faster and deliver higher quality. Mike Milinkovich commented that he likes this idea for further enhancement, and asked how people will participate if they don't want to sign the Oracle Contributor Agreement (OCA). Is there an advantage to being on an Expert Group at all? Brian took the action item to follow up wit Oracle legal on the terms of the JSPA and OCA. Brain also clarified that the Dev mailing list is under GPL terms, but the spec mailing lists are under JCP terms and conditions.
The ther action item from previous Working Group meeting was clarification on the EDR license used. Brian summarized the feedback from Oracle legal regarding the EDR license terms around implementations, specifically that evolving open independent implementations is allowed, with the caveat that implementations need to move to the final version once it ships. The EDR license says that you license and carry disclaimer about evaluation only; you can add disclaimer on license. Mike Milinkovich and Scott Stark commented that they would follow up with their legal teams to clarify if that will work for their use.
Brian commented that because many EDR iterations would have been publicly available by the time a feature reaches readiness, we might want to discuss how to shorten the JSR review periods. For example, do we need 30 day review periods if we are creating bi-weekly drops. Heather asked the EC if they would be willing to consider these types of changes to section 3.4 of the JCP Process Document as part of the JCP.Next effort. Brian elaborated that we want to minimize overhead of starting a new JSR for every platform release; would it be possible to have multiple Fi nal Releases of a Java Platform Umbrella JSR, and plan to release a smaller set of features, then we can have more predictable releases that developers can plan for. Mike DeNicola commented that customers often don't move or adopt the major releases. David Blevins commented that he was not sure if eliminating the creation of new JSRs would shrink overhead and that the JCP process and creation of a new JSR provides checks and balances. Scott Stark questioned whether the way patent and IP works in the JSPA if we could allow multiple Final Releases. Heather agreed that this is an issue to explore further.
Heather summarized the latest meeting of the JCP.Next Working Group. The proposed plan is to get agreement from the EC to submit the JSR to the PMO and form the Expert Group, consisting of the JCP EC Members. Heather would serve as the Spec Lead and we would continue with a Working Group to do the majority of the work on the JSR, and report on the progress at our EC Meetings. Heather suggested that we find anther time, preferably in the morning for the Working Group to meet since the attendance in the Working Group meetings has been low, and some EC Members based in Europe are not available for the Tuesday afternoon Pacific Time meeting. Heather will initiate another poll to determine the new meeting time. Heather summarized the items for inclusion in the JSR - the primary focus of the JSR will be on collaborative reference implementation (RI) development, with the goal of ensuring that none of the JCP's processes inhibit collaborative development processes. The JSR will implement changes that will build on the reforms that began with JSR 348 and continued with JSR 364, making the work of the JCP more open and transparent, and enabling broad participation. Mike Milinkovich noted that it is problematic to define collaborative development and we agreed to discuss another way to phrase this. David Blevins asked about requiring Spec Leads to maintain a TCK issue tracker. Heather noted that we are purposely not specific in the process document about specifics of how Spec Leads implement their transparency requirements in both the public discussion forum and the issue tracker, and that the focus of this JSR is not on TCK development and most Spec Leads are not developing their TCK in the open. Further discussion can happen in the Working Group. Heather asked the EC to review the JSR drat. Following the agreement of the new meeting time, we will meet again and finalize the JSR Proposal for submission and approval by the EC.
Heather summarized the status of the Java ME Working Group. Leonardo Lima presented the Java ME Working Group results (see the presentation for details). Florian Touinier presented Oracle's plans for future Java ME directions (see the presentation for details). Mike Milinkovich asked whether a third party spec lead for Java ME was possible. Heather VanCura stated that the current process rules allow for this. Oleg Pachkovets commented that he was expecting Oracle to convince Gemalto and others to lead JSRs and what was meant by allowing JSR leadership for now. Georges Saab clarified that Oracle was open to this option if there are JCP Members in leading JSRs in this space now, but they are not planning to submit new JSRs at this time. Oracle will evaluate over time the investment in Java ME. Oleg Pachkovets commented that Oracle is missing the IoT market, the largest growing market, Mike Milinkovich stated that we should mend fences in this space between OSGi and Jigsaw. Georges Saab clarified that Jigsaw is not intended as the only solution. Mike Milinkovich asked if Oracle would consider changing its business model from relying on the field of use restrictions and instead focus on long term support contracts to enable wider scale adoption of Java overall. Florian agreed to participate in future Java ME Working Group meetings to continue the discussion. Next meeting will be 24 May.
Santiago Pericas-Geersten gave a status update on JSR 370 (see the presentation for details).
Werner Keil gave a presentation on a JSR 363 Implementation Example (see the presentation for details).
Heather reminded EC members that the next EC Meeting is a public EC Meeting (second hour is public) and asked for agenda suggestions. We will welcome new JCP EC members and introduce them.
Heather invited EC Members to attend the Austin JUG meeting that evening, and then thanked V2COM for their hospitality and the meeting adjourned.