 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
Executive Committee Meeting Minutes
|
Tuesday May 10 |
PMO |
|
Executive Committee |
Total attendance: 24 of 25 voting members |
| Since 75% of the EC's voting members were present, the EC was quorate for this session |
Wednesday May 11 |
PMO |
|
Executive Committee |
Total attendance: 24 of 25 voting members |
| Since 75% of the EC's 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):
There was no change in voting privilege as a result of this meeting.
See the JIRA.
While reviewing Action Items Bruno Souza noted that the decommissioning of java.net will be a big problem for SouJava. (The new Java Community Portal is not a complete replacement, since provides no mailing-list capabilities.) They have thousands of email messages on java.net and are not sure how to export them or where they can export them to. (They do believe they will be able to export Issues from the java.net JIRA into GitHub.)
Patrick responded that we are still holding internal discussions about alternatives to java.net, and that as the AI states we will address this issue in a future meeting.
Patrick presented the usual EC stats (see the presentation for details).
Patrick introduced what was expected to be a brief discussion about the implementation of JSR 364 (see the PMO Presentation for details). He reported that after some initial glitches the PMO expects that the new features on jcp.org (including electronic signing of membership agreements) will go live next week. [This has since happened.] He expressed some concern about the delay in going live, noting that there will only be a few months before this year's elections, and suggested that we will need to monitor the number of Associate members in the hope that we will have a critical mass for the elections. (We don't want a small number of Associate members to have the power to vote for two Associate seats.)
The question was raised as to whether we should continue with the plan of record (to hold the 2016 elections under the new process) or whether we should wait until the 2017 elections before we do so. Either way we will need an energetic drive to recruit new Associate members and to convert existing individual members into Associate members where necessary.
Bruno Souza argued strongly for holding the 2016 election under the new rules, saying that that we will simply have to work harder to recruit new members. He suggested that if all EC members joined in the recruitment effort then we ought to be able to achieve our goals. Mike DeNicola responded that we ought not to rush, but should proceed in an orderly fashion.
We had a lengthy discussion about how to handle individual members whose membership agreements come up for renewal between now and the election. Several EC members argued that we should not "force" these members to convert to the new Associate membership class, since to do so would discriminate against them in comparison to those members whose agreements would not come up for renewal until after the election. We agreed with this proposal.
We discussed the different options open to us. We discussed whether we should unconditionally wait until 2017 to implement the new election process, hold the 2016 elections under the new rules if we reach a certain number (150?) of Associate members before then andotherwise wait until 2017, or unconditionally implement the 2016 election under the new rules no matter how many Associate members we have.
After a lengthy discussion, during which we realized that any option other than unconditionally holding the 2016 elections under the new process (which is what we wrote into the Process Document) would require a Maintenance Release of JSR 364, we held a straw-poll. A substantial majority voted to unconditionally hold the 2016 elections under the new process.
Florian Denzin presented an interesting overview of Gemalto's use of Java in the IoT space (see the presentation for details).
Werner Keil presented an overview of the use of Java in the automotive industry (see the presentation for details). During the discussion that followed members with direct experience in the automotive industry explained why due to safety and liability concerns Java has not been used to actually control critical functions in cars (the engine or brakes for example), typically being restricted to infotainment, communications, and similar non-critical functions.
Martijn Verburg led a discussion on the future of Java EE. [This agenda item was originally intended to result in a formal motion from the EC requesting a public response from Oracle on its commitment and plans for Java EE.]
Martijn expressed concern that Oracle, despite its role as steward of Java, has not made any public statements or explanations for the apparent lack of activity on Java EE. He said that the London Java Community represents a large number of developers, many of whom are employed at large financial institutions that rely significantly on Java EE. Otavio Santana agreed with Martijn, saying that there seem to be "no signs of life" in Java EE. Martijn responded that they do recognize that over the years Oracle has made a very significant investment in Java EE.
Mike DeNicola pointed out that the EC has a responsibility to raise issues and concerns. Steve Wallin said that IBM was also concerned. Simon Ritter pointed out that the impact is broader than Java EE itself, asking what the purpose of the JCP itself would be in the absence of Java EE JSRs. Christoph Engelbert noted the almost complete lack of any JSR activity.
Don Deutsch responded that he understood EC members' concerns. He suggested that some new JSRs might be filed later, but said he couldn't be sure. Business strategies are subject to change. He noted that a formal motion might not be the most constructive approach, and wondered whether EC members would consider an alternative. He asked whether EC members would be willing to contribute to Java EE.
Romain Pelisse pointed out that it would be difficult for others to take over, since most of the Java EE JSRs are owned by Oracle. SImon Ritter noted that the issue of IP ownership is key and asked whether Oracle would be willing to contribute its IP so others could take over. Mike Milinkovich agreed, arguing for an orderly transition of Spec Lead responsibilities. Steve Wallin suggested that either a new ecosystem will emerge or there will be a fork. Gil Tene pointed out that Oracle could keep the Spec Lead role if it simply permitted others to participate.
Mike Milinkovich pointed out that Oracle's Spec Leads seem to be 100% devoted to the "Cloud pivot" rather than to their Java EE roles. Mike DeNicola said that Fujitsu has many customers that rely on Java EE and that they they will lose face and lose customers if platform development is discontinued. Steve Wallin said that Java EE is critical for IBM.
Gil Tene asked whether there is an alternative to a formal motion. Mike DeNicola said that we do seem to have a consensus. He asked Don Deutsch whether Oracle would vote for such a motion. Don responded that he would probably abstain. He asked what direction EC members wanted the platform to take. Mike responded that any direction is better than none. Martijn Verburg responded that the first job ought to be to complete Java EE 8.
Patrick pointed out that all EC meeting minutes are public, so that even in the absence of a formal motion EC members' views would be heard. He and Don then suggested that instead of a formal motion we should summarize EC members' concerns in the meeting minutes, and that they would then bring this to the attention of Oracle's management. Patrick agreed to summarize the concerns, and pointed out that members would have a chance to review the statement and to make corrections before the minutes are made public. [Statement follows:]
"EC members expressed their serious concerns about the lack of progress on Java EE. They believe that Java EE is critical to the Java ecosystem and to their organizations and customers. They fully accept Oracle's right to direct its investment where it wishes, but expressed the hope that they and other members of the Java community be permitted to step in and help with the ongoing development of the platform, particularly in areas where Oracle wishes to reduce its investment. They therefore requested a dialog with Oracle about how to make such a transition."
We adjourned early on the first day in order to spend some time socializing as a group before either going on to a group dinner or to a meeting with the Berlin Java User Group.
Bruno Souza and Otavio Santana discussed the previous evening's JUG meeting and their plans to meet with several other European JUGs. They reported that the Berlin JUG meeting had been very successful, with approximately ten EC members attending. The JUG members were pleased to meet EC members in person, and had many questions for us. They then explained their plans to meet with other JUGs in Germany, Switzerland, and Spain, and to record interviews and discussions with various Java luminaries along the way (see their presentation for details).
Bruno Souza introduced a guest speaker - Ruslan Synytskiy, CEO of Jelastic, who spoke briefly to the EC about his experiences in trying to run Java in a shared hosting ("Cloud") environment. Ruslan explained that Java SE seems not to be designed for such an environment, where ideally it would grow and shrink its memory footprint elastically as demand changes. The JVM, on the other hand, tends to grab all available resources and not to release them.
An interesting discussion followed, during which Gil Tene, Steve Wallin and others discussed the difficulty of doing what Jelastic wanted. They argued that while this is not impossible it is extremely difficult since it is often not possible to tell "from the outside" whether memory held by the JVM is actually in use by live objects or could potentially be freed. They suggested that additional APIs would be needed so that an external "supervisor" could communicate with the JVM to request that it release memory.
We concluded that the best approach to take would be through OpenJDK, where a working group of interested and technically qualified people could investigate further.
Patrick led a brief discussion of the Maintenance Release process (see the PMO Presentation for details). As we have during previous discussions, we agreed that the current language in the Process Document on what is appropriate for inclusion in a Maintenance Release is satisfactory:
"Changes appropriate for a Maintenance Release include bug-fixes, clarifications of the Specification, changes to the implementation of existing APIs, and implementation-specific enhancements. Changes introduced in Maintenance Re-leases – for example, modifications to existing APIs or the addition of new APIs - must not break binary compatibility as defined by the Java Language Specification. Changes that would break binary compatibility should therefore be deferred to a new JSR."
We did agree that additional minor changes to the Maintenance Release process should be considered in JCP.next.5.
We then returned to the topic (discussed in previous meetings) of OpenJDK and the JCP. Gil Tene argued for a "binding commitment" to existing OpenJDK practices (collaborative development and the Community TCK License) along the lines discussed in "Oracle Commitments" made early in the JSR 358 process. Patrick argued that the relevant items had already been incorporated into the list of changes for inclusion in JCP.next.5. Gil agreed to review the early presentations again and to come back to this topic in the future.
In a more wide-ranging discussion members again expressed their concerns that JSRs coming out of the OpenJDK process come so late that the JCP can do little but rubber-stamp them.
Mike Milinkovich suggested that we go back to first principles and discuss the value that the JCP brings to the process: enabling multiple implementations and the enforcement of compatibility through TCK licensing. He suggested that we need a more collaborate relationship with the Java SE Expert Group.
We agreed that it would be helpful if the OpenJDK leaders came to talk directly to the EC. Patrick explained that he expected an approach from Georges Saab relatively soon.
Hendrik Hoefer presented an overview of a potential new JSR in the automotive/telematics area (see his presentation for details). Members expressed great interest in the possibility of a new JSR in this area and wished Hendrik success in initiating it.
Due to a lack of time we postponed this topic to a future meeting.
After a brief discussion about meeting in Bangalore in January and in Sweden in May 2017, we agreed - again in the interests of time - to continue this discussion by email. [Twitter later confirmed by email that they will host our September f2f meeting in San Francisco.]
Patrick thanked Gemalto for hosting the meeting and we then adjourned.
