EG Meeting Minutes: Mon 14 Jan 2019

Iris Clark iris.clark at oracle.com
Fri Jan 25 17:49:56 UTC 2019 

Hi.

I've attached minutes for our meeting on 14 Jan.

Please provide update to this thread as necessary.

Thanks,
Iris
-------------- next part --------------
Java SE 12 (JSR 386) and Java SE 13 (JSR 388)
Expert Group minutes: 2019/01/14

Attendees: Brian Goetz (Oracle), Manoj Palat (Eclipse Foundation), Simon
Ritter (Azul Systems, Inc.)  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
------
- Amber hyphenated keywords (Manoj)
- JDK 12 retrospective
  - Raw string literals ??? proposed and pulled back
  - Preview features - how to ensure adequate feedback?
- JCP 2.11 process update ??? what to expect going forward
- JSR 388 (Java SE 13) startup
- OpenJDK Contributors Workshop ??? coming up in Feb
- API documentation licenses (Volker)

Brian started the meeting by wishing everybody a "Happy New Year".
Referencing the previously sent agenda, he asked if there were any additional
items. Manoj and Volker contributed "Amber hyphenated keywords" and "API
documentation licenses" respectively.


Amber hyphenated keywords
-------------------------

Manoj asked about the recent proposal in [Project Amber][amber] to add
[hyphenated keywords][amberHyphen].  Brian said that it was an idea that has
received positive responses.  He believed that the proposal avoided
difficulties associated with conditional keywords and would be easier for
tooling.  Brian was hoping to get more direct development feedback on the
[amber-dev mailing list][amberDev].  Manoj also asked whether there were plans
for changes to switch expressions.  Brian replied that there were no plans at
this point and he was happy with things as they were.  There was a suggestion
on the list to change the 'break' keyword to something like 'breakwith' on the
assumption that it would be a straightforward change; however, the suggestion
did not stimulate any discussion.  Brian encouraged people with opinions to
reply on the list.

[amber]: https://openjdk.java.net/projects/amber/
[amberHyphen]:
https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-January/000945.html
[amberDev]: https://mail.openjdk.java.net/mailman/listinfo/amber-dev


JDK 12 retrospective
--------------------

Brian reported that JDK 12 (the RI for JSR 386) reached the "Feature Freeze"
milestone in December and that RDP2 (Rampdown Phase 2) was imminent.  He
believed that overall it was a smooth release and commented that in contrast
to releases prior to the six month cadence, the transition to the next release
seemed relatively stress-free.  Brian believed that the new cadence was an
enormous success for developers and that the transition had gone better than
he had imagined.  Additional education for users was still needed.

Moving to [raw string literals][jep326], Simon noted that removing the
language feature from the release was evidence that preview features were
working as they should.  Brian said that he was apprehensive about removing
them late in the release; however, feedback from the Community has indicated
that it was the correct decision.  Simon observed that a six month delay was
minor compared to the fact that Java had lived without them for 23 years.
Brian believed that raw string literals were solidified prematurely and work
on them continued.  He expected an updated proposal for Java SE 13.

Brian described the [preview feature][jep12] mechanism timeline saying that
for Java SE 12, the RI Feature Freeze was in December with release the
following March.  For SE 13, the RI Feature Freeze would be in June, three
months later at which time, the disposition of the preview feature would be
decided.  He wondered whether three months was sufficient time to receive
feedback for that decision.  Brian did not want to preview features for a
year; however, he was concerned about the small window.  Simon said that the
simplest answer was to preview for a year.  Volker noted that [HTTP2][jep321]
required two releases before it became standard.  He believed that enterprise
users would not move to SE 12.  Brian also understood that many users would
never touch preview features; however, they existed to solicit for more
feedback than was received from [EA binaries][ea12] before the feature was
finalized.  Volker observed that the huge code bases of enterprise developers
made it unlikely that they would ever compile with a preview feature enabled.

Manoj explained that Eclipse delivered a stable release every three months.
Support for SE 12 would be in the Eclipse stable release three months after SE
12 was released; however, proactive users could download a patch the day after
the SE 12 released.  Eclipse expected a three month minimum before most users
would be using the new SE release.  When asked how users were notified of new
releases, Manoj said that users would need to find the release on the Eclipsea
web page.  There was no explicit user notification.

Brian summarized that while the preview feature concept was good, the new
release cadence may require adjustments for these feature to receive a
reasonable amount of feedback.  Volker asked whether the "six months" was
defined in the JEP describing preview features.  Brian replied that it was
not.  Preview features are not permanent.  Explicit action must be taken for
them to remain in the next release.  The choices are to become a permanent
feature or to preview for another release, just like [incubating
modules][jep11].  Brian thought that it would be unfortunate if a preview
feature was renewed for another release then received no additional feedback.
Volker wondered if the lack of feedback indicated whether nobody was using the
feature or it worked well.  Volker recommended using preview features to
implement the JDK itself since that would almost certainly guarantee feedback;
however, he understood that this decision involved some cost if the feature
changes or is removed.  Brian added that use in the JDK would likely discover
corner cases; however, careful consideration would be necessary before using
preview features in the JDK.  Volker said that if the feature was 99%
complete, then it should be trusted for use.

Manoj asked whether preview features could be in a Long-Term Support (LTS)
release.  Brian answered saying that any release may have preview features.
For example, say the next LTS release is Java SE 17 and it contains a preview
feature.  Presumably the feature would be promoted in Java SE 18 or 19, but
those using them in Java SE 17 after SE 18 (or SE 19) was released would still
need to turn the features on at compile and runtime.

[jep326]: https://openjdk.java.net/jeps/326
[jep12]: https://openjdk.java.net/jeps/11X
[jep321]: https://openjdk.java.net/jeps/321
[ea12]: https://jdk.java.net/12/
[jep11]: https://openjdk.java.net/jeps/11


JCP 2.11 process update
-----------------------

Brian said that the JCP process was now at version 2.11, having recently been
streamlined via [JSR 387][jsr387].  The changes were around recognizing that
we are on a more rapid release schedule.  The Early Draft Review (EDR)
milestone was replaced with continuous drafts as announced by Iris.  There
were also changes to the end of the JSR life-cycle.  Previously, three
milestones came in quick succession: Public Review (PR), Proposed Final Draft
(PFD), and Final Approval Ballot (FAB).  Now there is a Public Release (PR)
followed by a ballot then a Final Release (FR) that does not have a ballot;
however, the constraint was that only minor corrections and clarifications
were appropriate after PR.  He suggested thinking of PR as the "Specification
Feature Freeze".  Brian said that JCP 2.11 was in line what how things worked
for Java SE specification development now.

Brian asked whether JSR 386 (Java SE 12) should change to JCP 2.11.  He said
that the benefits were obvious and the risk was that some people in the JCP
may be upset that they did not get an opportunity to express their concerns.
Simon understood Brian's concern, but thought that JSR 386 should switch to
the new process.  Based on feedback he had heard, he did not think anybody
would notice or be upset.  Volker said that the JCP unanimously voted to
approve JSR 387 and the Platform JSR use case was considered during the
development of JCP 2.11.  He did not think there would be any problems and
supported moving to the latest JCP process.  Wrapping up the topic, Brain took
an action item to propose moving to JCP 2.11 on the [EG mailing list][eglist]
so that Andrew and Tim could comment before a decision was made one week
hence, Mon 21 Jan.

[jsr387]: https://jcp.org/en/jsr/detail?id=387
[eglist]: https://mail.openjdk.java.net/mailman/listinfo/java-se-spec-experts


JSR 388 (Java SE 13) startup
----------------------------

Brian began this topic saying that [JSE 388 (Java SE 13)][388] should be the
last JSR that would need an approval vote to begin and that subsequent JSRs
would be automatically renewed.  Brian warmly welcomed Manoj (Eclipse
Foundation) to the EG saying that he particularly looked forward to their
feedback for new features from the tooling perspective.

Manoj observed that with so many language features being developed and
discussed on the mailing lists, it would be nice if there was a dashboard of
features expected within the next few years.  Brian replied that there were
still struggles around the best way handle this kind of planning as it may be
perceived as commitments.  He liked the idea of a flexible roadmap and pointed
to the development progression of the pattern matching feature which was
delivered in phases.  It was hard to deliver in a flexible manner with enough
lead time for tooling to be ready for the next release.  Out-of-band
conversations were in progress to bridge this gap but a more organized and
public mechanism was needed. Manoj said that quite a bit of work on a feature
usually occurred before Eclipse had the resources to begin their work and they
could focus on only one or two features at a time.

Finishing the topic of , Brian asked whether the [JEP][jep388] and
{CSR][csr388] dashboards were up.  Iris replied that they went up in December.
Manoj said that his team used them periodically; however, they wanted more of
a "big picture roadmap" for planning.  Brian replied that he would think about
possible solutions.  The concern was that any time a feature is associated
with a release, a promise was made to deliver.

[jsr388]: https://jcp.org/en/jsr/detail?id=388
[jep388]: https://bugs.openjdk.java.net/secure/Dashboard.jspa?selectPageId=18216
[csr388]: https://bugs.openjdk.java.net/secure/Dashboard.jspa?selectPageId=18217


OpenJDK Contributors' Workshop (OCW)
------------------------------------

Brian said that [OCW][ocw] would be held on Monday, 4 February immediately
after [FOSDEM '19][fosdem19] (Brussels, 2 & 3 Feb).  A registration process
had not been announced but was expected to be light.  He commented that OCW in
August 2018 was very successful.  Brian expected the February 2019 OCW would
have a different composition due to the location.

[ocw]: https://openjdk.java.net/workshop
[fosdem19]: https://fosdem.org/2019/


337, 384 Maintenance Reviews (MRs)
----------------------------------

Iris started by saying that while Maintenance Reviews did not have Expert
Groups, she wanted to provide a brief status for the expected work for the
[JSR 337][jsr337] (Java SE 8) and [JSR 384][jsr384] (Java SE 11) MRs.  The MRs
will address a targeted number of critical issues related to support for
external standards as described in the message cross-posted to
[jdk8u-dev][jdk8u] and [jdk-updates-dev][jdku].  The specification changes
would be developed and contributed following the standard processes for the
respective OpenJDK Projects.  Iris expected that the affected project's
maintainers would work together on the mechanics of the integration of the
resulting changes into the appropriate forests and repositories in the coming
weeks.

[jsr337]: https://jcp.org/en/jsr/detail?id=337
[jsr384]: https://jcp.org/en/jsr/detail?id=384
[jdku]: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-December/000308.html
[jdk8u]: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-December/008324.html


API documentation licenses
--------------------------

Volker described his concern by saying that the API documentation for the
Reference Implementation (RI) is all under the [GNU General Public
License][gpl]; however, when the JavaDoc API is generated from that
documentation it is under different licenses which do not permit
redistribution.  He wanted a configurable solution.  Brian reiterated Volker's
concern to verify his understanding and said that he would need to
investigate.

[gpl]: https://openjdk.java.net/legal/gplv2+ce.html

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