From brian.goetz at oracle.com Fri Dec 1 18:41:34 2017 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 1 Dec 2017 13:41:34 -0500 Subject: Updating the version number Message-ID: <08f94193-623b-3147-ebfa-7cb975d398fa@oracle.com> I am sure everyone has seen the extensive discussions on version numbers.? Mark has recently posted a JEP capturing a concrete proposal: ??? http://openjdk.java.net/jeps/8192828 The high-order bit here is that we're proposing going back to numbering things 10, 11, 12, including the platform specification. JSR-383 (https://jcp.org/en/jsr/detail?id=383) contains 11 occurrences of the string "18.3": - Title - Description - 2.1 Proposed Specification (2x) - 2.3 - 2.14 links - 2.15 RI and TCK (2x) - 2.19 link - 2.20 link - 3 Contributions Assuming no one here objects, I will ask the PMO to change all of the non-link usages of "18.3" in the JSR to "10 (18.3)", as in "Java SE 10 (18.3)" or "The Java SE 10 (18.3) Platform Specification". I will propose a similar change for JSR-384 (Java SE 18.9) once that JSR is approved and the EG formed. From volker.simonis at gmail.com Mon Dec 4 09:46:30 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 4 Dec 2017 10:46:30 +0100 Subject: Updating the version number In-Reply-To: <08f94193-623b-3147-ebfa-7cb975d398fa@oracle.com> References: <08f94193-623b-3147-ebfa-7cb975d398fa@oracle.com> Message-ID: Why do we need to keep "(18.3)" in the name? In my personal opinion that version schema was a mistake and there's no need to keep any reference to it. "Java SE 10 (18.3)" looks rather confusing to me as opposed to simply saying "Java SE 10". On Fri, Dec 1, 2017 at 7:41 PM, Brian Goetz wrote: > I am sure everyone has seen the extensive discussions on version numbers. > Mark has recently posted a JEP capturing a concrete proposal: > > http://openjdk.java.net/jeps/8192828 > > The high-order bit here is that we're proposing going back to numbering > things 10, 11, 12, including the platform specification. > > JSR-383 (https://jcp.org/en/jsr/detail?id=383) contains 11 occurrences of > the string "18.3": > > - Title > - Description > - 2.1 Proposed Specification (2x) > - 2.3 > - 2.14 links > - 2.15 RI and TCK (2x) > - 2.19 link > - 2.20 link > - 3 Contributions > > Assuming no one here objects, I will ask the PMO to change all of the > non-link usages of "18.3" in the JSR to "10 (18.3)", as in "Java SE 10 > (18.3)" or "The Java SE 10 (18.3) Platform Specification". > > I will propose a similar change for JSR-384 (Java SE 18.9) once that JSR is > approved and the EG formed. > > From brian.goetz at oracle.com Tue Dec 5 14:09:05 2017 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 5 Dec 2017 09:09:05 -0500 Subject: Updating the version number In-Reply-To: References: <08f94193-623b-3147-ebfa-7cb975d398fa@oracle.com> Message-ID: The simple answer is: JSR 383 was known as "Java SE 18.3" from its inception, so we retain it parenthetically to reduce confusion and maintain continuity.? I realize you view the calendar-based version scheme as a mistake that ought to be erased from history with all possible prejudice, but it makes sense to err on the side of continuity with existing published information.? So, I encourage you to look at this change as "glass 99% full" rather than "glass 1% empty." My interpretation of your comment is that it is not an objection, simply a regret that we couldn't go farther.? If my interpretation is incorrect, please correct me.? I want to get this to the PMO as soon as possible. On 12/4/2017 4:46 AM, Volker Simonis wrote: > Why do we need to keep "(18.3)" in the name? In my personal opinion > that version schema was a mistake and there's no need to keep any > reference to it. "Java SE 10 (18.3)" looks rather confusing to me as > opposed to simply saying "Java SE 10". > > > On Fri, Dec 1, 2017 at 7:41 PM, Brian Goetz wrote: >> I am sure everyone has seen the extensive discussions on version numbers. >> Mark has recently posted a JEP capturing a concrete proposal: >> >> http://openjdk.java.net/jeps/8192828 >> >> The high-order bit here is that we're proposing going back to numbering >> things 10, 11, 12, including the platform specification. >> >> JSR-383 (https://jcp.org/en/jsr/detail?id=383) contains 11 occurrences of >> the string "18.3": >> >> - Title >> - Description >> - 2.1 Proposed Specification (2x) >> - 2.3 >> - 2.14 links >> - 2.15 RI and TCK (2x) >> - 2.19 link >> - 2.20 link >> - 3 Contributions >> >> Assuming no one here objects, I will ask the PMO to change all of the >> non-link usages of "18.3" in the JSR to "10 (18.3)", as in "Java SE 10 >> (18.3)" or "The Java SE 10 (18.3) Platform Specification". >> >> I will propose a similar change for JSR-384 (Java SE 18.9) once that JSR is >> approved and the EG formed. >> >> From iris.clark at oracle.com Tue Dec 5 18:00:07 2017 From: iris.clark at oracle.com (Iris Clark) Date: Tue, 5 Dec 2017 10:00:07 -0800 (PST) Subject: [JSR 383: Java SE 10 (18.3)] JEP 314 Proposed to Target Message-ID: The following JEP is of scope "SE" and has been Proposed to Target for Java SE 10: 314: Additional Unicode Language-Tag Extensions http://openjdk.java.net/jeps/314 The announced deadline for feedback to jdk-dev is Tue 12 Dec 16:00 UTC: http://mail.openjdk.java.net/pipermail/jdk-dev/2017-December/000336.html Thanks, Iris From iris.clark at oracle.com Wed Dec 6 20:38:43 2017 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 6 Dec 2017 12:38:43 -0800 (PST) Subject: Java SE 18.3 PR Specification posted to jcp.org Message-ID: <0802fd88-fca4-4282-8983-81d176776feb@default> FYI: https://jcp.org/en/jsr/detail?id=383 This PR is based on build 33. For you convenience, it may also be viewed here: http://cr.openjdk.java.net/~iris/se/18.3/pr/java-se-18.3-pr-spec/java-se-18.3-pr-spec.html The Public Review period ends Tue 1 Jan. As usual, feedback is always welcome. Thanks, Iris From iris.clark at oracle.com Thu Dec 7 04:23:23 2017 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 6 Dec 2017 20:23:23 -0800 (PST) Subject: [JSR 383: Java SE 10 (18.3)] JEP 322 Proposed to Target Message-ID: <83dbe19a-921b-4021-962d-3216347b9aec@default> The following JEP of scope "SE" has been Proposed to Target for Java SE 10: 322: Time-Based Release Versioning http://openjdk.java.net/jeps/322 The announced deadline for feedback to jdk-dev is Wed 13 Dec at 23:00 UTC: http://mail.openjdk.java.net/pipermail/jdk-dev/2017-December/000352.html Thanks, Iris From iris.clark at oracle.com Thu Dec 7 06:53:32 2017 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 6 Dec 2017 22:53:32 -0800 (PST) Subject: JavaDoc API and diffs for Java SE 10 (18.3) build 34 posted Message-ID: <23304d2c-e41b-43bd-846f-ad76633e0d81@default> The JavaDoc API and diffs against build 34 (10+33 vs 10+34 and 9+181 vs 10+34) are now available: http://cr.openjdk.java.net/~iris/se/10/build/34/ Thanks, Iris From iris.clark at oracle.com Fri Dec 8 19:41:00 2017 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 8 Dec 2017 11:41:00 -0800 (PST) Subject: EG Meeting Minutes: Thu 7 Dec 2017 Message-ID: <958abb10-9fc8-4345-8f99-35bd3ccd757c@default> Hi. I've attached minutes for our meeting on Thu 7 Dec. Please provide updates on this thread if necessary. Thanks, Iris -------------- next part -------------- Java SE 10 (18.3) (JSR 383) Expert Group minutes: 2017/12/07 Attendees: Tim Ellison (IBM), Brian Goetz (Oracle) 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 ------ - JDK 10 - JSRs 383 and 384 - Incubator Modules - JEP Process - Next meeting JDK 10 Status ------------- Brian started the meeting by saying that [JDK 10][jdk10] development was about a week away from Feature Freeze (a.k.a. Rampdown Phase One (RDP1)). A fork of the repository would occur soon. JDK 10 stabilization would proceed in the fork and the mainline would be used for JDK 11. Changesets pushed to the JDK 10 repository would be automatically pushed to the mainline at least until the next milestone. New features are not expected after Feature Freeze. A flurry of smallish things to fix bugs is expected so there will probably be more movement on the [CSR Dashboard][csr] than on the [JEP Dashboard][jep]. Reviewing the JEP Dashboard, Brian said that there were three SE-scoped JEPs in JDK 10. [JEP 286: Local-Variable Type Inference][286] is the largest and was discussed at the last Expert Group (EG) meeting. [JEP 314: Additional Unicode Language-Tag Extensions][314] contains updates for Unicode support. [JEP 322: Time-Based Release Versioning][322] is the long-awaited update of the version string. Brian did not think that either of the last two JEPs should be controversial at this point. Brian summarized the JDK status saying that while Java SE 10 was not a big release since it had only one highly visible feature, the release did shake out the process to smoothly deliver releases on a six month cadence. Brian added that the CSR Dashboard with filtering for Scope = "SE" contained dozens of smaller enhancements and fixes. If that filtering is removed, then even more changes could be seen. He reminded the EG that the filtering allowed the EG to focus on those things which impacted the Java SE Platform Specification. Tim mentioned that he needed to find the link to the CSR Dashboard. Iris replied that it could be found on the [383 EG webpage][383]. Brian briefly described how to easily modify a given filter to remove the "SE" Scope (click on the numerical summary at the end of a table to go to an editable filter). For the Dashboards, removing the "SE" Scope reveals work with Scope "JDK" or "Implementation". JSRs 383 and 384 ---------------- Summarizing the JSR 383 status, Brian said that the [Public Release][383pr] had been published. It had a somewhat longer review period due to the holidays. The Public Review Ballot would begin 2 Jan immediately following the close of Public Review. The next milestone, Proposed Final Draft, is expected to occur after the close of development, Rampdown Phase 2 (RDP2) in mid-January. [JSR 384][384] for Java SE 11 completed JSR Review earlier this week. The ballot ends on 11 December. Once the ballot has completed, the Expert Group list on the JCP site will fill out based on the already accepted nominations. Incubator Modules ----------------- Volker asked about the status of [Incubator Modules (JEP 11)][11]. He reminded the EG that Java SE 9 contains one incubator module, [JEP 110: HTTP/2 Client][110] and that the Incubator JEP declared that such modules would defer standardization for one release. At the next release, incubator modules should be finalized or removed. Brian replied that JEP 11 was written under the old release cadence. The HTTP/2 Client was updated and re-enlisted for another round of incubation with the expectation that it would be finalized in Java SE 12. Tim noted that if an API is being improved via incubation, a finalization or removal decision should not be made just because time had expired. He did not think that the original time constraint should be applied in this case. Brian agreed saying that incubator modules solved two problems. First, they gave an API broader distribution to collect additional feedback and experience before standardization. Next, the limited life-span prevented creation of a "dumping ground" for half-finished work. Brian added that broadening incubation for all platform features was under consideration. Guidelines for successful incubation of a VM or Language feature were currently being drafted. The expectation was that compilation and runtime would need to explicitly enable the feature so that users could not accidentally rely on it. Tim asked how a decision to incubate was made. Brian answered that it was done through the JEP process. A feature would Propose to Target or incubate for a given release. Tim asked whether build distributors could add any incubator modules. Brian answered that there was a distinction between Language and VM changes which are tightly controlled and features which carry their own specification with them. IBM had the right to bundle everything in Maven Central (for instance); however, there were constraints on the namespace. Volker said that incubator modules should` reside in the 'jdk.incubator' namespace as described by the JEP. Tim wanted to ensure that the distinction between incubator modules and standard features be apparent to developers to avoid fragmentation. Brian responded that the design of incubator modules included solutions to avoid fragmentation. In particular, incubator modules are not resolved by default for applications on the class path, at least for the OpenJDK implementation. The expectation was that incubating VM and Language features would leverage the 'java -release' option added in Java SE 9, perhaps by adding an option to access incubating features for the release. Tim liked the mechanism of using the runtime to control access to incubating features. Brian expected a proposal for incubator VM and Language features in the next month or two. Volker observed that there were a few problem with the HTTP/2 Client incubator module, in particular it had insufficient visibility, it was only in OpenJDK, and it could not be used as a stand-alone API. Brian thought that there was always more room to publicize features; however, a side-effect of the faster cadence was that if somebody wanted to influence the content of the JDK, they would need to follow things closely. Volker wondered whether HTTP/2 Client should have been developed as a JSR. Brian expected that it would not have received more visibility and feedback but there would have been more paperwork. Volker countered that as a JSR it would not have been baked into OpenJDK and could be easily used by other vendors. He asked whether it would be possible for incubator modules to be provided outside the context of the Platform. Tim was not convinced that was a reasonable, general requirement. Brian declared that there was no impediment to providing builds of individual features; however, it was historically challenging for Oracle to do so. He encouraged projects to distribute their work using appropriate channels. JEP Process ----------- Moving to the JEP Process, Volker thought it was working fairly well; however it was difficult to find supporting materials to evaluate a JEP that was Proposed to Target (PPT). Some JEPs use webrevs to distribute their code, others have implementations in other OpenJDK Projects, or in sandbox branches. The current state made it extremely difficult for porters to determine what work was required. He requested more information in the PPT announcement which currently contains only a link to the JEP. Brian summarized Volker's concern saying that moving a JEP to PPT was an alert to pay attention; however, there was no consistent means to determine where attention should be directed. Brian said that cultural expectations, tooling, and process could be used to address the described problem and that additional process was the least desirable solution. He continued saying that identifying a general solution was difficult. He thought it was reasonable to try to capture the locations of a JEP's supporting materials by setting cultural conventions and additional tooling. Volker agreed that conventions such as those used for e-mailed review requests (e.g. loosely structured "Subject:" lines or JDK Updates approval requests) were needed. Brian believed that it would be possible to make some improvements and suggested scanning mailing lists for JEP-related changesets. When he speculated that Tim might be thinking about practical solutions from [AdoptOpenJDK][aojdk], Tim agreed. During the above conversation, Volker noted that that the [JEP 2.0 Process Proposal][jep2.0] still needed to be finalized. Next meeting ------------ Brian asked whether the EG preferred to meet in a month or communicate via e-mail. After a brief discussion the EG decided hold another video call in mid- to late January. Brian will organize the meeting. [jdk10]: http://openjdk.java.net/projects/jdk/10/ [csr]: https://bugs.openjdk.java.net/secure/Dashboard.jspa?selectPageId=17600 [jep]: https://bugs.openjdk.java.net/secure/Dashboard.jspa?selectPageId=17511 [286]: http://openjdk.java.net/jeps/286 [314]: http://openjdk.java.net/jeps/314 [322]: http://openjdk.java.net/jeps/322 [383]: http://openjdk.java.net/projects/jdk/18.3/spec/ [383pr]: https://jcp.org/aboutJava/communityprocess/pr/jsr383/index.html [384]: https://www.jcp.org/en/jsr/detail?id=384 [320]: http://openjdk.java.net/jeps/320 [11]: http://openjdk.java.net/jeps/11 [110]: http://openjdk.java.net/jeps/110 [aojdk]: https://adoptopenjdk.net/ [jep2.0]: http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From brian.goetz at oracle.com Thu Dec 14 18:29:07 2017 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 14 Dec 2017 13:29:07 -0500 Subject: JEP 309 targeted Message-ID: <1922db42-16d5-a6c2-826c-b8fd25658196@oracle.com> FYI: the following JEP has been targeted to *11*: ??? https://bugs.openjdk.java.net/browse/JDK-8177279 (We have not yet forked for 11, so it won't be pushed until after the fork.)