EG Meeting Minutes: Thu 7 Dec 2017

Fri Dec 8 19:41:00 UTC 2017

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