EG Meeting Minutes: Thu 12 Oct 2017
Iris Clark
iris.clark at oracle.com
Mon Oct 16 21:25:28 UTC 2017
Hi.
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.
Thanks,
Iris
[0] http://mail.openjdk.java.net/pipermail/java-se-spec-experts/2017-October/000000.html
-------------- 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.
Agenda
------
- 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
JEP
---
- OpenJDK JEP Process
http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
- 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
https://bugs.openjdk.java.net/secure/Dashboard.jspa?selectPageId=17511
- 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
impediment.
- 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
this.
- 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.
CSR
---
- OpenJDK Compatibiilty and Specification Review (CSR) Process
https://wiki.openjdk.java.net/display/csr/Main
- CSR Dashboard
https://bugs.openjdk.java.net/secure/Dashboard.jspa?selectPageId=17600
- 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
http://cr.openjdk.java.net/~iris/se/18.3/spec/26/api
- diffs from last build
http://cr.openjdk.java.net/~iris/se/18.3/spec/26/diffsFrom10+25
- diffs from SE 9
http://cr.openjdk.java.net/~iris/se/18.3/spec/26/diffsFrom9+181
- 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
http://cr.openjdk.java.net/~dlsmith/local-var-inference.html
- Brian described this as diffs against the JLS which we'd like to be
automatic.
- 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
http://openjdk.java.net/projects/jdk/18.3/
- JCP
http://openjdk.java.net/projects/jdk/18.3/spec
- 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
TCK.
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 http://openjdk.java.net/projects/jdk/18.3/spec, "Mailing
lists".)
More information about the java-se-spec-observers
mailing list