Iris Clark recently published the Java SE Expert Group Meeting Minutes for 14 January 2019 on the java-se-spec-experts OpenJDK mailing list. Clark's minutes are highly approachable and written in a conversational style. These notes provide insight into what members of the Java SE Expert Group consider current, near-term, and long-term topics for Java SE's future. They cover topics that include the proposal for hyphenated keywords (including whether to change the switch expression's current break to break-with.), a JDK 12 retrospective with focus on the preview feature process, JSR 388 (Java SE 13) startup, and concerns about API documentation licenses.

Perhaps most interesting to me from Clark's 14 January 2019 EG Meeting Minutes is the summary of the discussion on the introduction and subsequent dropping of the raw string literals feature specifically and the preview feature process more generally. According to the minutes, Simon Ritter "noted that removing the language feature from the release was evidence that preview features were working as they should." The minutes also state that Brian Goetz "believed that raw string literals were solidified prematurely and work on them continued," but that he expects "an updated proposal for Java SE 13."

The meeting minutes provide some additional interesting commentary on the preview features process:

• How much time should be provided for preview feature discussion?
  • "Brian summarized that while the preview feature concept was good, the new release cadence may require adjustments for these features to receive a reasonable amount of feedback."
  • Duration of "six months" is NOT "defined in the JEP describing preview features."
• "Volkner ... believed that enterprise users would not move to SE 12."
• "Volker observed that the huge code bases of enterprise developers made it unlikely that they would ever compile with a preview feature enabled."
• "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]."
• Does "lack of feedback [on a preview feature] indicate ... nobody was using the feature or it worked well?"
  • Should a preview feature be used in the JDK itself to improve the likelihood of use of the feature and accompanying feedback?
  • Any release (including a Long-Term Support [LTS] release) can include a preview feature.

I found the 14 January Meeting Notes of the Java SE Expert Group to be an interesting read. It sounds like the preview feature approach is generally working and will continue to be used to introduce features for preview before committing them to the specification.