EG Meeting Minutes: Thu 12 Oct 2017

Iris Clark iris.clark at
Mon Oct 16 21:25:28 UTC 2017


I've attached minutes for our meeting on Thu 12 Oct. They provide
additional context for Brian's welcome message [0].

Please provide updates on this thread if necessary.


-------------- next part --------------
Java SE 18.3 (JSR 383)
Expert Group minutes: 2017/10/12

Attendees: Tim Ellison (IBM), Andrew Haley (Red Hat), Brian Goetz (Oracle)
Volker Simonis (SAP SE), Simon Ritter (Azul Systems, Inc.), and Iris Clark
(Oracle, minutes)

The intent of these minutes is to caputure the conversational flow of the
discussion and to record any decisions and follow-up items.


  - OpenJDK JEP Process
  - OpenJDK CSR Process
  - EG status dashboards in the OpenJDK Bug System
    - JEP
    - CSR
  - EG discussion artifacts
    - JavaDoc API for the most recent build
    - diffs from last build
    - diffs from SE 9
    - Specification for JEP 286: Local Variable Type Inference
  - EG questions and concerns
  - Working arrangements
  - Responsibilities of Spec Leads and EG members
  - Schedule alignment
    - OpenJDK
    - JCP


- OpenJDK JEP Process
  - Brian directed attention to the "Workflow" diagram near the middle of the
    document.  He described JEPs as a communication vehicle and a program
    management tracking artifact and briefly described each of the states.
  - Brian identified the transition to "Propose to target" state as important
    to the EG.  At this point, the draft specification should be ready for
    evaluation by a wider audience.
  - Volker pointed out that JEP 2.0 Process is still a proposal and
    recommended that it become the official process.  He noted that the
    present state was very confusing for those who wished to submit JEPs.
    It was generally agreed that this was unnecessarily confusing, and Oracle
    indicated that it would be addressing this.

- JEP Dashboard
  - Brian said that all listed JEPs had a Scope of "SE", meaning that they all
    had an impact to the Java SE specification. "JDK" and "Implementation" are
    other values of "Scope".
  - Tim thought the dashboard ordering was unexpected.  Brian noted that items
    in the "green" section had no expectations for which release they'd be
    in and the bar for being in draft was quite low, only basic socialization.
  - Brian said that when a JEP comes to "Propose to target", it would need to
    move to "Targeted" relatively quickly; hence EG member evaluation would
    necessarily occur quickly.  The review process should not be viewed as an
  - Simon asked whether there would be "rolling JSRs".  Brian confirmed,
    saying that the internal process for the Java SE 18.9 JSR had already
    started.  This EG will use long-running mailing lists.
  - Brian declared that it is highly desirable that there be continuity in the
    platform EG and we are doing everything we can within the bounds of the
    process, such as rolling mailing lists. However, the JCP currently
    requires us to propose a new JSR for every platform version.  We are
    looking into whether it is worth modifying the JCP process to support
  - Brian commented that the dashboard filters could be used to generate
    e-mail notifications.

- Roles of the JDK Project and the JSR 383 EG
  - Tim wanted to know what the relationship was with the Project Lead since
    JEP disposition is determined by the Project Lead.  He didn't want any
    reason for misunderstanding.
  - Brian said that this was something that needed to be worked out.  The JDK
    Project and EG deliberations have slightly different goals.  The EG is
    concerned with completeness of the specification.  The JDK Project focuses
    on stewardship and implementation.  They can live concurrently, but
    coordination would be important.
  - Andrew emphasized the need for clarity regarding the overlapping roles of
    the Project Lead and the EG.  He thought more thought was required to
    clearly define these roles.
  - Brian responded saying that he was open to suggestions.

- Paths into the Platform Specification
  - Volker pointed out difficulties in getting Group sponsorship for JEPs.
  - Brian said that a JSR was an alternative mechanism for getting features
    into the Platform Specification.  However, Project JDK provides the
    reference implementation so at some point, a JEP would be created.  He
    continued saying that Oracle had chosen to do most of its work via
    OpenJDK because was more inclusive.
  - Andrew disagreed with the "inclusive" characterization.
  - Tim requested verification that JSRs would could still influence the
    Platform Specification.  Brian replied saying that a Platform
    Specification could continue to reference component JSRs as in the past;
    ultimately, a JEP would still be required for the Reference Implementation
    (RI) of the JSR.
  - Simon (playing devil's advocate) thought that the bar for getting a JEP
    accepted may provide a useful filter.  Brian elaborated saying that the
    level of scrutiny depended on the level of impact.  Adding a new method
    would require less evaluation than changing the language.


- OpenJDK Compatibiilty and Specification Review (CSR) Process
- CSR Dashboard
  - Brian opened this topic saying that the CSR Process is the replacement for
    an old, internal process referred to as "CCC".  CSR is essentially a way
    to capture all proposed specification changes.  The CSR Group's members
    are concerned with specification clarity and presentation issues and
    ensure they are reviewed by specification experts.  An SE Scope JEP must
    have at least one CSR for it to move to "Propose to target".

- Feature Readiness
  - Tim (referring to a JEP) asked how a JEP owner would be provided feedback
    that they're going to miss the release.  Brian replied saying that there
    was no mechanism or "secret list".  A feature is not targeted until it is
    complete.  Part of the target decision includes a risk assessment to
    determine whether the JEP can make the next release, or whether it should
    wait for the following release.
  - Volker wanted to understand how feature readiness is determined,
    particularly given the short window between RI milestone Feature Freeze
    and General Availability (GA).
  - Brian said that there was a distinction between problems and objections.
    Objections should be raised at "Propose to target" (or before) and should
    be addressed before "Targeted". Some problems could be addressed after a
    JEP is "Integrated".  If a feature is a complete disaster, then it could
    be backed out.  In the event that option wasn't practical, then the entire
    release could be backed out to some previous state.  Finally, the "nuclear
    option" would be to ship the previous release.
  - Andrew commented that we'd have to respect the fact that it would be
    difficult to get things done in three months, even if most of the
    development occurred before then.
  - Brian concluded saying that more attention would be necessary on a more
    continuous basis.

EG discussion artifacts

- JavaDoc API for the most recent build
- diffs from last build
- diffs from SE 9

  - Brian said that the JavaDoc API and two diffs are currently manually
    generated and published.  The intention is to provide these diffs weekly
    (per promotion).
  - Brian noted that the diffs are imperfect as they contain spurious diffs.
    There is work underway to improve them.

- Specification for JEP 286: Local Variable Type Inference
  - Brian described this as diffs against the JLS which we'd like to be
  - Volker said that he'd tried to look at the feature but couldn't easily
    find builds.  He wanted to know whether there were plans to make things
    easier to test.  He reminded Brian that this was particularly important
    given the three month testing window.  Brian said that we'd love to have
    great binary builds for all in-process featuers, particularly for
    stakeholders,  but there are various challenges to providing them.

EG questions and concerns

- "Late binding"?
  - Brian provided the following description.  There's a development window
    of six months.  At the end of the window, the repository forks a
    "stabilization branch (at RI milestone "Rampdown Phase 1, "RDP1").  While
    RDP1 is the latest a new feature would be considered for a release, in
    reality, that's too late for many features.  A new bug fix or a tiny
    feature may be reasonable, but it's too late for a language feature.
    Those changes are more suitable for the next release with integration
    early in the next window.  Whether a JEP is "Targeted" to a particular
    release depends on the perceived size and risk.
  - Simon added that he understood that the release repository would be
    feature complete at any time.
  - Volker noted that the even though there are releases every six months,
    everybody would want to get their features into the Long Term Support
    (LTS) releases.
  - Brian commented that whether a release is LTS should not be part of the
    targeting decision.  The only considerations should be whether the
    feature is ready and the risk given the schedule.

Schedule alignment

- OpenJDK
  - Brian started by saying that in-flight updates to the JCP process (as part
    of the JSR 364 Maintenance Review) would produce more flexibility. He
    thought it made sense to align the JCP PR milestone with the RI RDP1.  A
    two week window for PR would provide the opportunity to act on feedback
    prior to RDP1.
  - Tim was not convinced that there would be much feedback during PR and
    thought that deadlines should be set based on the times you wan
  - Simon asked how much feedback was typically received.  Brian answered
    "almost none".
  - Volker wanted to know whether there would be Early Access builds.  Brian
    confirmed and added that the repository fork for 18.9 would occur in
    mid-December, as suggested by the 18.3 development schedule.

- TCK for JSR 383 (aka JCK)
  - Andrew asked whether the TCK would continue to be developed internally by
    Oracle.  Brian responded saying that in the long term, it was desirable
    for the TCK to be developed in OpenJDK; however, he did not see this
    changing in the 18.3 time-frame.
  - Volker wondered whether it would be possible to make the JCK available
    under an OpenJDK license earlier than a few weeks after GA.  Brian replied
    saying that the TCK can't be declared complete until the final
    specification change has occurred; hence, late specification changes
    result in late TCK changes.
  - Volker noted that the OpenJDK Community received the TCK after Licensees.

  AI [Brian]: Determine constraints in providing earlier Community access to

Working arrangements

- Meetings
  - Andrew recommended monthly meetings.
  - E-mail interactions would be more frequent.

  AI [Brian]: Determine meeting schedule.

- Mailing lists
  - Brian assured Tim that the usual trio of OpenJDK JSR mailing lists would
    be used. (See, "Mailing

More information about the java-se-spec-experts mailing list