From iris.clark at oracle.com Wed Mar 14 20:33:00 2018 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 14 Mar 2018 13:33:00 -0700 (PDT) Subject: JSR 383 (Java SE 10 (18.3)) Final Release Message-ID: Hi. The JCP EC approved the Final Release Specification on 5 March. The Final Release version of the JSR 383 Specification, with instructions on how to find the RI and the TCK, is here: https://jcp.org/aboutJava/communityprocess/final/jsr383/index.html I've updated the primary web page for the JSR accordingly: http://openjdk.java.net/projects/jdk/10/spec/ Thank you for your participation. The 383 EG is now disbanded. Iris From iris.clark at oracle.com Thu Mar 15 21:04:01 2018 From: iris.clark at oracle.com (Iris Clark) Date: Thu, 15 Mar 2018 14:04:01 -0700 (PDT) Subject: EG Meeting Minutes: Mon 26 Feb 2018 Message-ID: <54f88513-c019-47a2-a3c9-5065447ec815@default> Hi. I've attached minutes for our meeting on 26 Feb. Please provide updates to this thread as necessary. Thanks, Iris -------------- next part -------------- Java SE 10 (18.3) (JSR 383) and Java SE 11 (18.9) (JSR 384) Expert Group minutes: 2018/02/26 Attendees: Tim Ellison (IBM), Brian Goetz (Oracle) Andrew Haley (Red Hat), Volker Simonis (SAP SE), and Iris Clark (Oracle, minutes) The intent of these minutes is to capture the conversational flow of the discussion and to record any decisions and follow-up items. Agenda ------ On SE 10 - Update on PFD and FAB - Postmortem on 10 process On SE 11 - EDR to be posted Tuesday - Review of dashboards for SE 11, linked from http://openjdk.java.net/projects/jdk/11/spec/ - JEPs https://bugs.openjdk.java.net/secure/Dashboard.jspa?selectPageId=17668 - CSRs https://bugs.openjdk.java.net/secure/Dashboard.jspa?selectPageId=17669 - Summary of future milestones General - Incubating JEPs - Any other items the EG wants to discuss Brian started the meeting by providing a brief summary of the agenda. He said that SE 10 was in the home stretch, SE 11 was about to reach its first JCP milestone, and it was time to file the JSR for SE 12. He commented that the rapid train schedule seemed to be working. The agenda also included items that weren't tied to a particular version. He knew that Volker had thoughts on incubating language features. Andrew asked Tim, as a representative of a team doing an entirely independent VM, how he was managing with rate of change. Tim answered that the rate of change was not related to the release schedule. The IBM development team saw the flow of JEPs and other work at the same rate. There was a change in Release Engineering, but since IBM provided monthly releases, the new release model was more of a benefit than a determent. Brian was interested in understanding accidental consequences of the new release model. Tim replied that the biggest problems were based on understanding what the six month release represents and the role of LTS verses a commercial release. He thought that additional clarity was needed to distinguish between an OpenJDK Community offering and an Oracle offering. Six months is the OpenJDK release cycle. "LTS" is an Oracle (commercial) offering. Brian expected that the rapid release cycle would be confusing for a while, but that eventually it would be understood. Tim commented that even sophisticated users have expressed surprise about what an LTS is and the relationship between release timelines. On SE 10 -------- Brian reported that SE 10 (JSR 383) FAB (JCP milestone "Final Approval Ballot") was scheduled to begin Tue 27 Feb. He noted that the final DRAFT material would be included with the Ballot. When he asked whether everybody had received the DRAFT material, Tim asked whether everybody was getting the TCK at the same time. Brian replied that commercial licensees received it first. Iris provided a time-line for early-access TCK distribution saying that after a TCK promotion, it was posted for commercial licensees. Distribution to Red Hat and others occurred a few days after that. Tim was particularly concerned about timing differences because he wished to avoid surprises which may occur if the test suite was distributed late in the release cycle. After Volker described SAPs understanding of their access to the TCK, Brian commented that there were many different arrangements. He thought the lack of uniformity was a transition issue which should be addressed. Over the past release, the focus had been on the RI and the Spec. The point was taken that intermediate TCK builds should be uniformly accessible to those who require it for EG work. Brian stated that his end goal was for all TCK work to be in the open. He expected that the first step was for new TCK tests to be developed in the open. Tim thought that was a laudable goal. Beyond TCK access, Brian asked whether there were things which could be done to improve the process. He referenced the handful of in-person meetings, dashboards, and weekly build artifacts. Tim thought that the dashboards were definitely useful. Brian declared that they could be changed if additional information was desired. Volker said he found the apidiffs helpful. Brian reported that work was being done to improve and open-source the specdiff tool. Andrew observed that the process of putting together the Specification had changed and had gotten more transparent. However, the problem with the approach was that it appeared that JEPs just showed up and were bundled into the Specification. He did not understand how it was coordinated into a coherent Java. From the Expert Group (EG) point of view, it seemed to be more about following correct processes, not evaluating whether the a good programming language or set of libraries was produced. Andrew emphasized that he was not worried about any particular feature. Brian agreed having a better process for externalization of the roadmap would be a good thing, and commented that "we'd like to have already done this, but of course, this is no small task and frequently competes for attention and resources with more urgent things, so it make take some more time." Brian anticipated that if there was a more externalized roadmap for the VM, GC, Libraries, etc. there would be more opportunities for the Community to participate in the process, and that this might be the mechanism that Tim and Andrew were looking for. He mentioned that defining the roadmap was a full-time commitment while reviewing an existing roadmap required much less time. Brian added that he'd be thrilled to have others participate. He encouraged EG members to contribute their time and expertise directly in OpenJDK where most development was occurring. Brian concluded saying that he would try to define a better model. Andrew commented that the [JVM Language Summit][jvmls] was fantastic since many roadmap aspects were discussed. He thought that being physically removed from his day-to-day job helped and that if such detail was provided in a mailing list he would not have time to read it. Brian stated that while he hoped that everybody could come to the Java Language Summit, it should not be the only forum where the Platform's direction was discussed. [jvmls]: http://openjdk.java.net/projects/mlvm/jvmlangsummit/index.html On SE 11 -------- Brian reported that SE 11 (JSR 384) was underway and that the EDR (JCP milestone "Early Draft Review") would be posted Tue 27 Feb. He reminded the EG that the EDR was a requirement of the JCP; however, since builds were published every week, it should not treated as a significant milestone by th EG. Brian reminded the EG that links to [JEP][JEP] and [CSR][CSR] Dashboards were provided in the Agenda and are on the [JSR 384][384] page. Brian observed that the current set of JEPs already in SE 11 consisted of one significant addition ([JEP 309][309]) and one significant subtraction ([JEP 320][320]). The VM feature, Dynamic Class-File Constants ([JEP 309][309]), was an extension of [JSR 292][292]. Brian offered to go through the list of JEP aspirations, but none were Proposed to Target yet. The next JCP milestone is PR (Public Review), scheduled April, near the end of the development window. [JEP]: https://bugs.openjdk.java.net/secure/Dashboard.jspa?selectPageId=17668 [CSR]: https://bugs.openjdk.java.net/secure/Dashboard.jspa?selectPageId=17669 [384]: http://openjdk.java.net/projects/jdk/11/spec [320]: http://openjdk.java.net/jeps/320 [309]: http://openjdk.java.net/jeps/309 [292]: https://jcp.org/en/jsr/detail?id=292 On SE 12 -------- Brian declared that it was time to begin filing the internal paperwork to submit a JSR for Java SE 12. The EG should expect a JCP Review Ballot in the next few months. Volker asked why the value of the system property 'java.vendor.version' and the version info now display '18.3' for both OpenJDK and Oracle builds. He thought this would be confusing to users and wanted to understand the reason behind the '18.3'. Brian replied that he thought that the '18.3' would only be applied to Oracle JDK builds which are expected to align with Oracle products which use dated versions. Since he did not expect OpenJDK builds to use this number, Brian said he would investigate. When asked about IBM's use of a 'java.vendor.version' of '18.3' , Tim replied that they planned to avoid it. Incubating JEP -------------- Brian introduced this topic by referencing [Alex Buckley's proposal for incubating language features][iJEPs], a follow-on to what was done for libraries. The motivation is that the rapid release model caused ideas to move more quickly to a permanent part of the platform without the historical opportunity for feedback. The Incubating JEP provides a vehicle for shipping language features which are final pending a little bit of feedback and review. It also allowed easy experimentation. Tim reported that some of his colleagues loved the JEP and others hated it. He believed that those who were interested in the new features would have downloaded a separate build (as they did for Jigsaw) and others who were not interested would continue to ignore them. Brian replied that the goal was to lower the barrier to try the new features. Incubation sends a strong message that we are serious about a feature. Tim thought that if the quality level was high, there was value in having an incubating feature; however, it did introduce unnecessary overhead for the majority who would not use it. Brian emphasized that incubating features were for features that are mostly finished. Volker asked why the feature needed to be part of the Specification unlike incubating modules which were not. Brian explained that there is a huge ecosystem of libraries that are not part of the Spec (e.g. all of Maven Central) which users know how to handle. There is no parallel for language features and optional language features would invite fragmentation. He asserted that the longevity of the Java Language is a result of the integrity of the Spec. Fragmentation would lower the value of the Java language. Volker observed that the frequent release cadence had an impact since there would be more than 10 Specifications six years hence. Brian replied that Java SE 10 would have a Spec which would never change. Tim added that backwards compatibility would not be broken. To explore the possible impact, the conversation focused on a particular example of tools vendors. These vendors already need to support a new version every six months. Brian asserted that a feature incubating in Java SE 11 would become a permanent feature in almost the same form in Java SE 12. He asked how would the tools vendors implement the feature if there was no Spec. Volker thought that a feature Spec could exist, but not be part of SE. Tim noted that a Spec was necessary to work under the JCP. Volker countered that the Spec was already developed under a license which could be viewed by JCP members. After that Brian wondered how this made things any better. Tim suggested that Volker explain the value of moving the feature Spec out of Java SE. After further discussion, Brian said that for incubating features, the Spec would change. In six months, the feature would move out of the incubating annex to the main body of the Spec or completely dropped. The expectation was that the vast majority of the time, there would be no user-visible difference between a feature incubating in release 'N' and the final version in 'N+1'. If there are substantial differences, then the bar for incubation was too low. Early Adopters would have potentially one additional version of backward compatibility (a grace period for feature support). Adopters did not get to object if the feature was changed between releases 'N' and 'N+1'. Volker expressed his concern that it would be too easy to modify incubating language features; thus, leading to code which was no longer valid. He pointed to a case where a library feature was incubating in 9, changed and incubating in 10, with hopes of becoming standard in 11. Thus, there were three incompatible implementations of the same feature in three sequential versions of Java. To Brian, this sounded like Volker was against incubating features and suggested that one should wait to use incubating features until they were final if there was fear that code would become invalid. Volker returned to the question of why incubating modules were not part of the Spec. Brian explained that incubating modules were added before the rapid release cadence and that libraries outside of the Spec were common. He noted that the namespace of incubating modules was changed when they became standard. The most analogous thing is proposed for language features. Their use required a command-line flag at compile-time which produced a class file with a slightly different version number. Use of these class files required a VM command-line flag. Of course, the specific command-line flags for the compiler and launcher are not specified by the JCP, so all the Spec can say is that these flags are strongly encouraged. Volker asked Tim for his comments. Tim replied that he was not convinced that the incubating mechanism would drive people to try new technologies, but as it is part of a release, it needs to be part of the Spec. If feedback is valued, then an implementation needed to be provided. He thought that the bar for inclusion into the Annex was lower than it is for the main part of the Spec. Brian agreed with that evaluation. Brian speculated that the confusion between "incubating" and "experimental" features occurred because of poor naming. Tim noted that it was easier to explain if the different types of features were in different repositories and builds. Brian wondered whether "incubating features" should be renamed "preview features". Tim said that "incubating" implied instability that was not applicable. Andrew added that the term was from Apache, but the use was not the same. Brian thought that if the feature was more experimental, then Volker's concerns were fair; however, since these features were 99% done, a better name was needed. Brian invited the EG to suggest alternative names to the incubating "Incubating Language Features" JEP. and committed to clarifying the JPT to make the intent more clear. [iJEPs]: http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000515.html Noting the time, Brian asked for thoughts about the next meeting. Tim replied that he would like them to occur more regularly. Brian thought that sounded good. A target was set for 6-8 weeks. From iris.clark at oracle.com Thu Mar 29 20:46:20 2018 From: iris.clark at oracle.com (Iris Clark) Date: Thu, 29 Mar 2018 13:46:20 -0700 (PDT) Subject: [JSR 384: Java SE 11] JEP Propose to Target: 321: HTTP Client (Standard) Message-ID: <854528ef-4b89-4651-b44c-638eb860ce09@default> The following JEP of scope "SE" has been Proposed to Target for Java SE 11: 321: HTTP Client (Standard) http://openjdk.java.net/jeps/321 The announced deadline for feedback to jdk-dev is Thu 5 Apr at 23:00 UTC: http://mail.openjdk.java.net/pipermail/jdk-dev/2018-March/000996.html Thanks, Iris