 
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: 23 of 23 voting members plus 2 non-voting members |
| Since 75% of the EC's 23 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):
Since Ericsson and SAP have now attended two consecutive meetings they have regained their voting privileges.
See the JIRA.
Heather VanCura presented the usual EC stats (see the presentation for details).
We discussed JSR 377, which passed its JSR Renewal Ballot but with a significant number of no votes and abstentions. Patrick suggested that whenever a ballot occurs in which several EC members vote "no" or add comments we will follow up with the Spec Lead in an attempt to get the JSR back on track.
Heather discussed the JSR implementation plan. (See the PMO presentation for details.) We agreed that a first step towards generating materials for promoting JCP 2.10 will be for Patrick and Heather to update the presentations that they give a conferences and JUG meetings. The relevant portions of these presentations could then be abstracted into a set of standalone promotion materials.
We also reviewed the implementation checklist.
Patrick reported that JSR 358 has now been officially withdrawn and an explanation has been posted on the JSR page (see the PMO presentation for details). We agreed that the appropriate way to publicize this will be in the context of promoting JCP.next.5.
Martijn Verburg reported on behalf of the London Java Community that it now seems clear that little if any progress is being made on Oracle-led Java EE JSRs. (Some Oracle Spec Leads have admitted publicly that they are unable to spend any time on their JSRs, having been directed to work elsewhere.) He estimated that work on Java EE seems to have stopped around November 2015.
Martijn said that while he recognizes Oracle's absolute right to pursue a product strategy and allocate resources in ways that meet their business interests, the LJC is concerned that the lack of progress and the absence of any explanation from Oracle is doing significant harm to the Java community and ecosystem.
He explained that "splinter groups" are discussing taking over both the code work and thought leadership of Java EE, and that many companies are building proprietary frameworks such as microservices stacks, leading to even more fragmentation.
Chris Dennis wondered whether Oracle has lost interest altogether in Java EE or whether this is simply a temporary pause. If the former, could others pick up the work?
Martijn responded that we need an official statement from Oracle.
Geir Magnusson noted that Oracle has a good track record of understanding market trends, and suggested that perhaps the classic Java EE development model is no longer relevant in a world of cloud-based services. He pointed out, however, that many companies have commercial interests in the classic Java EE model.
Bruno Souza pointed out that if Oracle decides not to pursue Java EE others in the community are interested in evolving it. Could they do so? He argued that this is why the JCP exists - to ensure that standards can continue to evolve - and that it is the responsibility of the EC to ensure that this is possible.
Chris agreed, pointing out that if Oracle is not interested the "Java EE Guardians" would like to continue to evolve the platform. He noted that even in a microservices world, Java EE - or at least the Servlet API - is still there (lower down in the stack).
Werner Keil referenced the "Unresponsive Spec Lead" language in the Process Document. Geir Magnusson responded that this does not address Intellectual Property (IP) issues.
Patrick responded that in practice the Process Document language simply provided a mechanism whereby the PMO could ask Oracle to replace the current Spec Lead. It would be much more difficult to force Oracle to relinquish the role and even if this was possible there would still be the question of IP. The JCP cannot (nor should it be able to) force a Spec Lead to license their IP to someone else. Unless the Spec Lead is willing to license IP it would be very difficult for someone to take over the Spec Lead role.
Bruno Souza asked what we can say to those in the community who want to continue working to advance Java EE. Should we suggest that they work on new JSRs? We don't want everybody working on their own proprietary versions of the technology.
Werner quoted some examples of successful transfers of Spec Lead responsibility (most recently the Portlet Bridge JSR, which was transferred from Oracle to Liferay). He also suggested that a shared Spec Lead role might be a solution.
Patrick responded that in the Liferay case Oracle was willing to transfer its IP. He suggested that we wait and see what the "splinter group" decides to do.
Mike DeNicola argued that the EC should formulate and express an opinion on what Oracle should do in the best interests of Java - that is its role.
Patrick said that he will certainly tell the relevant people inside Oracle that the EC is very concerned about the situation.
Mike argued that if Oracle did not respond to a request from the EC for a public statement that would reflect badly on their opinion of the JCP.
We then adjourned this discussion, anticipating that we would pick it up again at a future meeting.
Patrick reviewed the list of initiatives we have proposed to work on now that we expect to be spending much less time on JCP.next activities (see the PMO presentation for details). He suggested that one of the items - encouraging new JSRs - might help with Java EE, since even if progress on the platform JSR and its components is slow, new standalone JSRs (perhaps in the microservices area) could continue to move things forward. Bruno Souza agreed, suggesting that we could talk to the "Java EE Guardians" about this. Patrick responded that he did not think this is something that the EC should do officially. Members continued to discuss the Java EE situation, expressing concerns about the danger of a fork and of fragmentation in the market. Patrick reminded members that we had already spent a considerable amount of time on this topic, and moved on (back) to life after JCP.next. He provided a summary of efforts that are under way in the OpenJDK Adoption group, and suggested that the topic of relations between OpenJDK and the JCP could perhaps be best addressed in the context of JCP.next.5.
Patrick reviewed the list of potential changes for inclusion in JCP.next.5 (see the issues list) and then presented a draft of the JSR submission form. He suggested that the theme of this JSR should be "facilitating collaborative RI development". In this context we could focus on OpenJDK as well as on other collaborative RI development projects to ensure that our processes do not inhibit such development. Members suggested some minor changes to the language [this has now incorporated into the document].
Due to lack of time Patrick suggested that people review these materials after the meeting and send feedback by email. We then adjourned.
