EG Meeting Minutes: Mon 26 Feb 2018

[Iris Clark]

Hi.

I've attached minutes for our meeting on 26 Feb.  

Please provide updates to this thread as necessary.

Thanks,
Iris
-------------- next part --------------
Java SE 10 (18.3) (JSR 383) and Java SE 11 (18.9) (JSR 384)
Expert Group minutes: 2018/02/26

Attendees: Tim Ellison (IBM), Brian Goetz (Oracle) Andrew Haley (Red
Hat), 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
------

On SE 10
  - Update on PFD and FAB
  - Postmortem on 10 process

On SE 11
  - EDR to be posted Tuesday
  - Review of dashboards for SE 11, linked from
    http://openjdk.java.net/projects/jdk/11/spec/ 
    - JEPs
      https://bugs.openjdk.java.net/secure/Dashboard.jspa?selectPageId=17668
    - CSRs
      https://bugs.openjdk.java.net/secure/Dashboard.jspa?selectPageId=17669
  - Summary of future milestones

General
  - Incubating JEPs
  - Any other items the EG wants to discuss


Brian started the meeting by providing a brief summary of the agenda.  He said
that SE 10 was in the home stretch, SE 11 was about to reach its first JCP
milestone, and it was time to file the JSR for SE 12.  He commented that the
rapid train schedule seemed to be working.  The agenda also included items
that weren't tied to a particular version.  He knew that Volker had thoughts
on incubating language features.

Andrew asked Tim, as a representative of a team doing an entirely independent
VM, how he was managing with rate of change.  Tim answered that the rate of
change was not related to the release schedule.  The IBM development team saw
the flow of JEPs and other work at the same rate.  There was a change in
Release Engineering, but since IBM provided monthly releases, the new release
model was more of a benefit than a determent.

Brian was interested in understanding accidental consequences of the new
release model.  Tim replied that the biggest problems were based on
understanding what the six month release represents and the role of LTS verses
a commercial release.  He thought that additional clarity was needed to
distinguish between an OpenJDK Community offering and an Oracle offering.  Six
months is the OpenJDK release cycle.  "LTS" is an Oracle (commercial)
offering.  Brian expected that the rapid release cycle would be confusing for
a while, but that eventually it would be understood.  Tim commented that even
sophisticated users have expressed surprise about what an LTS is and the
relationship between release timelines.


On SE 10
--------

Brian reported that SE 10 (JSR 383) FAB (JCP milestone "Final Approval
Ballot") was scheduled to begin Tue 27 Feb.  He noted that the final DRAFT
material would be included with the Ballot.  When he asked whether everybody
had received the DRAFT material, Tim asked whether everybody was getting the
TCK at the same time.  Brian replied that commercial licensees received it
first.  Iris provided a time-line for early-access TCK distribution saying
that after a TCK promotion, it was posted for commercial licensees.
Distribution to Red Hat and others occurred a few days after that.  Tim was
particularly concerned about timing differences because he wished to avoid
surprises which may occur if the test suite was distributed late in the
release cycle.  After Volker described SAPs understanding of their access to
the TCK, Brian commented that there were many different arrangements.  He
thought the lack of uniformity was a transition issue which should be
addressed.  Over the past release, the focus had been on the RI and the Spec.
The point was taken that intermediate TCK builds should be uniformly
accessible to those who require it for EG work.  Brian stated that his end
goal was for all TCK work to be in the open.  He expected that the first step
was for new TCK tests to be developed in the open.  Tim thought that was a
laudable goal.

Beyond TCK access, Brian asked whether there were things which could be done
to improve the process.  He referenced the handful of in-person meetings,
dashboards, and weekly build artifacts.  Tim thought that the dashboards were
definitely useful.  Brian declared that they could be changed if additional
information was desired.  Volker said he found the apidiffs helpful.  Brian
reported that work was being done to improve and open-source the specdiff
tool.

Andrew observed that the process of putting together the Specification had
changed and had gotten more transparent.  However, the problem with the
approach was that it appeared that JEPs just showed up and were bundled into
the Specification.  He did not understand how it was coordinated into a
coherent Java.  From the Expert Group (EG) point of view, it seemed to be more
about following correct processes, not evaluating whether the a good
programming language or set of libraries was produced.  Andrew emphasized that
he was not worried about any particular feature.  Brian agreed having a better
process for externalization of the roadmap would be a good thing, and
commented that "we'd like to have already done this, but of course, this is no
small task and frequently competes for attention and resources with more
urgent things, so it make take some more time."  Brian anticipated that if
there was a more externalized roadmap for the VM, GC, Libraries, etc. there
would be more opportunities for the Community to participate in the process,
and that this might be the mechanism that Tim and Andrew were looking for.  He
mentioned that defining the roadmap was a full-time commitment while reviewing
an existing roadmap required much less time.  Brian added that he'd be
thrilled to have others participate.  He encouraged EG members to contribute
their time and expertise directly in OpenJDK where most development was
occurring.  Brian concluded saying that he would try to define a better model.

Andrew commented that the [JVM Language Summit][jvmls] was fantastic since
many roadmap aspects were discussed.  He thought that being physically removed
from his day-to-day job helped and that if such detail was provided in a
mailing list he would not have time to read it.  Brian stated that while he
hoped that everybody could come to the Java Language Summit, it should not be
the only forum where the Platform's direction was discussed.

[jvmls]: http://openjdk.java.net/projects/mlvm/jvmlangsummit/index.html


On SE 11
--------

Brian reported that SE 11 (JSR 384) was underway and that the EDR (JCP
milestone "Early Draft Review") would be posted Tue 27 Feb.  He reminded the
EG that the EDR was a requirement of the JCP; however, since builds were
published every week, it should not treated as a significant milestone by th
EG.  Brian reminded the EG that links to [JEP][JEP] and [CSR][CSR] Dashboards
were provided in the Agenda and are on the [JSR 384][384] page.  Brian
observed that the current set of JEPs already in SE 11 consisted of one
significant addition ([JEP 309][309]) and one significant subtraction ([JEP
320][320]).  The VM feature, Dynamic Class-File Constants ([JEP 309][309]),
was an extension of [JSR 292][292].  Brian offered to go through the list of
JEP aspirations, but none were Proposed to Target yet.  The next JCP milestone
is PR (Public Review), scheduled April, near the end of the development
window.

[JEP]: https://bugs.openjdk.java.net/secure/Dashboard.jspa?selectPageId=17668
[CSR]: https://bugs.openjdk.java.net/secure/Dashboard.jspa?selectPageId=17669
[384]: http://openjdk.java.net/projects/jdk/11/spec
[320]: http://openjdk.java.net/jeps/320
[309]: http://openjdk.java.net/jeps/309
[292]: https://jcp.org/en/jsr/detail?id=292


On SE 12
--------

Brian declared that it was time to begin filing the internal paperwork to
submit a JSR for Java SE 12.  The EG should expect a JCP Review Ballot in the
next few months.

Volker asked why the value of the system property 'java.vendor.version' and
the version info now display '18.3' for both OpenJDK and Oracle builds.  He
thought this would be confusing to users and wanted to understand the reason
behind the '18.3'.  Brian replied that he thought that the '18.3' would only
be applied to Oracle JDK builds which are expected to align with Oracle
products which use dated versions.  Since he did not expect OpenJDK builds to
use this number, Brian said he would investigate.  When asked about IBM's use
of a 'java.vendor.version' of '18.3' , Tim replied that they planned to avoid
it.


Incubating JEP
--------------

Brian introduced this topic by referencing [Alex Buckley's proposal for
incubating language features][iJEPs], a follow-on to what was done for
libraries.  The motivation is that the rapid release model caused ideas to
move more quickly to a permanent part of the platform without the historical
opportunity for feedback.  The Incubating JEP provides a vehicle for shipping
language features which are final pending a little bit of feedback and review.
It also allowed easy experimentation.  Tim reported that some of his
colleagues loved the JEP and others hated it.  He believed that those who were
interested in the new features would have downloaded a separate build (as they
did for Jigsaw) and others who were not interested would continue to ignore
them.  Brian replied that the goal was to lower the barrier to try the new
features.  Incubation sends a strong message that we are serious about a
feature.  Tim thought that if the quality level was high, there was value in
having an incubating feature; however, it did introduce unnecessary overhead
for the majority who would not use it.  Brian emphasized that incubating
features were for features that are mostly finished.

Volker asked why the feature needed to be part of the Specification unlike
incubating modules which were not.  Brian explained that there is a huge
ecosystem of libraries that are not part of the Spec (e.g. all of Maven
Central) which users know how to handle.  There is no parallel for language
features and optional language features would invite fragmentation.  He
asserted that the longevity of the Java Language is a result of the integrity
of the Spec.  Fragmentation would lower the value of the Java language.
Volker observed that the frequent release cadence had an impact since there
would be more than 10 Specifications six years hence.  Brian replied that Java
SE 10 would have a Spec which would never change.  Tim added that backwards
compatibility would not be broken.

To explore the possible impact, the conversation focused on a particular
example of tools vendors.  These vendors already need to support a new version
every six months.  Brian asserted that a feature incubating in Java SE 11
would become a permanent feature in almost the same form in Java SE 12.  He
asked how would the tools vendors implement the feature if there was no Spec.
Volker thought that a feature Spec could exist, but not be part of SE.  Tim
noted that a Spec was necessary to work under the JCP.  Volker countered that
the Spec was already developed under a license which could be viewed by JCP
members. After that Brian wondered how this made things any better.  Tim
suggested that Volker explain the value of moving the feature Spec out of Java
SE.

After further discussion, Brian said that for incubating features, the Spec
would change.  In six months, the feature would move out of the incubating
annex to the main body of the Spec or completely dropped.  The expectation was
that the vast majority of the time, there would be no user-visible difference
between a feature incubating in release 'N' and the final version in 'N+1'.
If there are substantial differences, then the bar for incubation was too low.
Early Adopters would have potentially one additional version of backward
compatibility (a grace period for feature support).  Adopters did not get to
object if the feature was changed between releases 'N' and 'N+1'.

Volker expressed his concern that it would be too easy to modify incubating
language features; thus, leading to code which was no longer valid.  He
pointed to a case where a library feature was incubating in 9, changed and
incubating in 10, with hopes of becoming standard in 11.  Thus, there were
three incompatible implementations of the same feature in three sequential
versions of Java.  To Brian, this sounded like Volker was against incubating
features and suggested that one should wait to use incubating features until
they were final if there was fear that code would become invalid.

Volker returned to the question of why incubating modules were not part of the
Spec.  Brian explained that incubating modules were added before the rapid
release cadence and that libraries outside of the Spec were common.  He noted
that the namespace of incubating modules was changed when they became
standard.  The most analogous thing is proposed for language features.  Their
use required a command-line flag at compile-time which produced a class file
with a slightly different version number.  Use of these class files required a
VM command-line flag.  Of course, the specific command-line flags for the
compiler and launcher are not specified by the JCP, so all the Spec can say is
that these flags are strongly encouraged.

Volker asked Tim for his comments.  Tim replied that he was not convinced that
the incubating mechanism would drive people to try new technologies, but as it
is part of a release, it needs to be part of the Spec.  If feedback is valued,
then an implementation needed to be provided.  He thought that the bar for
inclusion into the Annex was lower than it is for the main part of the Spec.
Brian agreed with that evaluation.

Brian speculated that the confusion between "incubating" and "experimental"
features occurred because of poor naming.  Tim noted that it was easier to
explain if the different types of features were in different repositories and
builds.  Brian wondered whether "incubating features" should be renamed
"preview features". Tim said that "incubating" implied instability that was
not applicable.  Andrew added that the term was from Apache, but the use was
not the same.  Brian thought that if the feature was more experimental, then
Volker's concerns were fair; however, since these features were 99% done, a
better name was needed.  Brian invited the EG to suggest alternative names to
the incubating "Incubating Language Features" JEP.  and committed to
clarifying the JPT to make the intent more clear.

[iJEPs]: http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000515.html


Noting the time, Brian asked for thoughts about the next meeting.  Tim replied
that he would like them to occur more regularly.  Brian thought that sounded
good.  A target was set for 6-8 weeks.