Java Predictions for 2021 on Foojay

Geertjan Wielenga has posted "Java Predictions for 2021" on Foojay Today. It is a collection of predictions about Java in 2021 from eight members of the Java community (Almas Baimagambetov, Stephen Chin, Brice Dutheil, Marcus Hirt, Reza Rahman, Matt Raible, Simon Ritter, and me). The predictions are concisely written and it's interesting to see the overlap between them while at the same time seeing how different parts of "Java" are important to different people. In this post, I elaborate a bit more on my predictions that were included in "Java Predictions for 2021".

I provided two somewhat related predictions for Java in 2021:

• "Records will likely be finalized in 2021 and will be widely popular with Java developers who are fortunate enough to work on a version of the JDK with final (not preview) Record support.
• The release of the OpenJDK 17 implementation in 2021 (which will be the foundation of Oracle's LTS version and other community members' LTS versions) will motivate many who are already working on versions of the JDK later than JDK 8 to start moving or investigate moving to JDK 17. However, JDK 8 will remain widely popular (probably will still be used by over half of Java developers), creating (in the long term) a bimodal distribution of most commonly used JDK versions (8 and 17)."

Java Records Final in 2021

The prediction that Java Records will be final in 2021 is not a risky one. Records have a been a "preview" feature in JDK 14 (JEP 359) and JDK 15 (JEP 384) and now JEP 395 "proposes to finalize the feature in JDK 16" (which is currently in Rampdown Phase One and is scheduled to be released for General Availability in March 2021). Because Records have been through two preview releases already, it seems unlikely that they won't be final as of JDK 16. In the event that they do need one more release, JDK 17 should be released in October 2021.

And Then There Were Two: JDK 8 and JDK 17

2021 will see the beginning of a move to a bimodial distribution of JDK releases most commnoly used. With JDK 17's likely release in October 2021, we'll likely see many Java shops that have already migrated to a version of JDK later than JDK 8 move to that newly released JDK 17. There have been some nice additions and improvements to OpenJDK (which is the foundation of several different JDK implementations) that have been added in recent versions of the JDK and JDK 17 will be an "LTS" (Long-term Support) release for many of the JDK implementations. As an "LTS" release, JDK 17 will appeal to Java shops that want to only be on versions with long-term support and JDK 17 will be the first since JDK 11 to have this status for many of the JDK implementations.

JDK 8 appears to still be the most widely used release of the Java even in 2020. There are several metrics and andecdotal evidence that suggest this. One example is the JetBrains 2020 Development Ecosystem survey that suggests that 75% of Java developers responding to the survey use JDK 8 (some of these developers use other versions of JDK as well) and the same chart shows 32% of responding Java developers use JDK 11. For reference, the 2019 and 2018 versions of this same survey indicated that 83% and 84% of Java developers used JDK 8 in 2019 and 2018 respectively.

JDK 8 is a version with long-term support (Oracle, for example, offers "extended support" for JDK 8 through December 2030) in several JDK implementations and some shops appear hesitant to move to JDK 9 with its introduced modularity support (and need for libraries and frameworks to support that as well). For those shops that have already migrated to a version of JDK later than JDK 8, it should be relatively easier to migrate to JDK 17. I think that some JDK 8 shops will be motivated to make the "big move" and, while doing that, will jump directly to JDK 17. However, I expect that we'll still see at least half of JDK developers still using JDK 8 even at the end of 2021. For the half of JDK users already using a version later than JDK 8 (not counting users of version of JDK before JDK 8), I think we'll begin to see them migrate to JDK 17 in 2021 and the following year or two. Within the next year or two, I expect most JDK developers will be working with JDK 8 or JDK 17.

There will, of course, be some small pockets of JDK developers using other versions before JDK 8, between JDK 8 and JDK 17 (perhaps because they use a feature or garbage collector no longer available in JDK 17), and newer versions of JDK as they are released in 2022.

"LTS" Among JDK Providers

The following are some roadmaps of various JDK vendors' JDK implementations that provide insight into each vendor's LTS concept. Although "LTS" often is referring to Oracle's plan regarding their JDK implementation built on top of OpenJDK, other JDK vendors have generally treated these "LTS" releases in similar manner.

• AdoptOpenJDK Support and Release Roadmap
  • Shows "Java 17" as LTS.
  • States, "In addition, every three years one feature release will be designated as a Long Term Supported (LTS) release. We will produce LTS releases for at least four years."
  • States, "As a general philosophy, AdoptOpenJDK will continue to build binaries for LTS releases as long as the corresponding upstream source is actively maintained."
• Oracle Java SE Support Roadmap
  • States, "For product releases after Java SE 8, Oracle will designate a release, every three years, as a Long-Term-Support (LTS) release. Java SE 11 is an LTS release."
• Azul Java Support Roadmap
  • References Long Term Support (LTS) and Medium Term Support (MTS) and states, "Releases designated as LTS are those same LTS releases as designated by Oracle and the OpenJDK community."
• Amazon Corretto
  • "Amazon Corretto 8 & 11 support extended" states, "Amazon is extending long-term support (LTS) for Amazon Corretto 8 from June 2023 to May 2026 and for Amazon Corretto 11 from August 2024 to September 2027. Long-term support (LTS) for Corretto includes security updates and specific performance enhancements released at least quarterly."

Looking Forward to 2021

Most of us are hoping for a better year in 2021 than we've experienced in 2020. The finalization of Java Records and General Availability of JDK 17 in 2021 are going to be significant positive events for Java developers and I'm hoping that these will only be a small representative sample of positive events and advancements that benefit a much wider population in 2021.

Project Amber Design Documents on GitHub

As discussed in a Brian Goetz post on the amber-spec-experts mailing list, an effort is currently underway for "migrating design docs to GitHub." The GitHub repository is openjdk/amber-docs and it already hosts some frequently-referenced Project Amber design documents.

The project's main README states that this repository "is for design notes, presentations, guides, FAQs, and other collateral surrounding OpenJDK Project Amber." It also explains the relationship between the Amber design documents in this repository with those hosted on the OpenJDK Project Amber site: "Most documents here are written in (pandoc) Markdown, and changes made to Markdown sources are automatically formatted and pushed to the OpenJDK website.

The Amber design documents hosted on openjdk/amber-docs are currently categorized as either design-notes or guides. Here are some of the Amber design documents already hosted in the new openjdk/amber-docs GitHub repository (mostly in GitHub-friendly MarkDown format):

• Design Notes
  • Towards Better Serialization
  • Data Classes and Sealed Types for Java
  • Extending switch for pattern matching
  • Pattern Matching for Java
  • Pattern Matching for Java -- Semantics
  • Pattern Matching for Java -- Runtime and Translation
  • Type patterns in switch
  • Symbolic References for Constants
  • Data Classes for Java (October 2017) (HTML)
  • Data Classes for Java (February 2018) (HTML)
• Guides
  • Local Variable Type Inference: Frequently Asked Questions
  • Local Variable Type Inference: Style Guidelines
  • Programmer's Guide to Text Blocks

The moving of OpenJDK source and artifacts to GitHub via Project Skara is paying benefits already in terms of accessibility for Java developers. The moving of Amber design documents to GitHub will likewise make these documents more readily available. As a side note, the OpenJDK design discussions and decisions are also often readily available from the relatively new Inside.java blog that features "news and views from the Java team at Oracle."

Although these Project Amber design documents have long been publicly available, this migration to GitHub should make them even easier to access and will likely increase awareness of and access to these documents. Undoubtedly, advantages inherent with a modern version control system will be gained including easier ability to make, review, track, audit, and contribute changes.

Finalizing instanceof Pattern Matching and Records in JDK 16

Gavin Bierman has recently posted two approachable posts regarding instanceof pattern matching and records on the amber-spec-experts mailing list and both posts are thorough but succinct. I recommend that anyone interested in the latest state of these two Project Amber initiatives read these posts: "Finalizing in JDK 16 - Pattern matching for instanceof" and "Finalizing in JDK 16 - Records". Even for those not interested in the details, it is probably interesting to see the likelihood of instanceof pattern matching and records being finalized in JDK 16.

Pattern Matching instanceof Operator

In "Finalizing in JDK 16 - Pattern matching for instanceof," Bierman writes: "In JDK 16 we are planning to finalize two JEPs: Pattern matching for instanceof and Records." About instanceof pattern matching, Bierman states, "Adding conditional pattern matching to an expression form is the main technical novelty of our design of this feature."

The "Finalizing in JDK 16 - Pattern matching for instanceof" post talks about advantages of the instanceof pattern matching approach. Advantages discussed in the post include refactoring of a "common programming pattern" (checking for instanceof and then explicitly casting the thing checked with instanceof to the type it was checked against) to smaller code that is more readable. Another discussed advantage is the ability "to compactly express things with expressions that are unnecessarily complicated using statements."

Bierman also discusses scope issues, local pattern variable "poisoning", and how these will be dealt with using "flow scoping." About this, Bierman writes:

Java already uses flow analysis - both in checking the access of local variables and blank final fields, and detecting unreachable statements. We lean on this concept to introduce the new notion of flow scoping. A pattern variable is only in scope where the compiler can deduce that the pattern has matched and the variable will be bound. This analysis is flow sensitive and works in a similar way to the existing analyses. ... The motto is "a pattern variable is in scope where it has definitely matched". This is intuitive, allows for the safe reuse of pattern variables, and Java developers are already used to flow sensitive analyses.

The post on instanceof pattern matching ends with a discussion of the "Swiss cheese property" ("unfortunate interaction of flow scoping and shadowing [local pattern variables shadowing a field declaration]") and expresses the hope that IDEs will help developers to deal with these unfortunate interactions.

Records

Bierman's post "Finalizing in JDK 16 - Records" provides some nice summary descriptions related to Records. The first is, "Record classes are a special kind of class that are used primarily to define a simple aggregate of values." This is immediately followed by, "Records can be thought of as nominal tuples; their declaration commits to a description of their state and given that their representation, as well as all of the interesting protocols an object might expose -- construction, property access, equality, etc -- are derived from that state description."

This post covers the "implicit declaration of a number of members" of a Record from the Record's "state description." The post also provides a brief overview of why a developer might "explicitly [provide] a canonical constructor" and how to do so. About this, Bierman writes, "The intention of a compact constructor declaration is that only validation and/or normalization code need be given in the constructor body; the remaining initialization code is automatically supplied by the compiler."

"Finalizing in JDK 16 - Records" also discusses canonical constructor accessibility, @Override, and general annotations related to Records. The post concludes by mentioning that Records can be declared locally and explains how this is an advantage for an expected common use case of Records: "Records will often be used as containers for intermediate data within method bodies. Being able to declare these record classes locally is essential to stop proliferation of classes."

Conclusion

The two Project Amber initiatives of instanceof pattern matching and records will be welcome additions to the Java programming language. Although these features have been available in versions of the JDK before JDK 16 as preview features, it will be their finalization (hopefully in JDK 16) that will enable many more developers to apply them in production code.

Updates on Valhalla and Amber Records (Mid-February 2020)

Two posts on OpenJDK mailing lists today summarize the status of Project Valhalla and Project Amber's Records.

Valhalla

Brian Goetz begins his post "Valhalla -- finding the primitives" with this sentence, "I think its worth reflecting on how far we've come in Valhalla, both for the specific designs in the VM and language, and the clarity of the basic concepts." This post contains a brief history of the major design models that have been employed with Valhalla to this point and talks about the advantages and disadvantages of each of these models.

About "Q World," Goetz writes (I've added the emphasis), "The idea was that we would declare a class as either a value class or a 'regular' class, and we would derive various properties based on that." Goetz outlines these properties:

Q-World: Differentiating Properties of Regular Versus Value Classes
Property	Regular Classes	Value Classes
Identity?	Yes	No
Nullable?	Yes	No
Reference types?	Yes	No

Goetz explains that "there were many aspects which were either confusing or unsatisfying" (he provides several examples of these) about the "Q World" approach and that the approach lacked a "clean story for migration."

Goetz describes "conflating" certain "distinctions" when working with "L World":

• "nullable vs non-nullable"
• "pass-by-reference vs pass-by-value / flattened"
• "reference type vs value type"
• "identity-ful vs identity-free"

Goetz discusses how the current state of Valhalla builds on lessons learned from the "Q World" and "L World" stages. He writes:

The primitive that Valhalla introduces into class declaration is whether the instances of the class have identity or not. Traditional classes are now revealed to be "identity classes"; the new kind (identity-free) are called "inline classes". (This might not be the final word on the subject.)

Another lesson learned in Valhalla efforts is summarized:

A big AHA of the recent iterations is that it makes sense to talk about both values of inline classes and references to those values. Reference type has (almost) nothing to do with inline vs identity -- it has to do with whether the value set of the type contains values, or references.

Based on these summarized observations, Goetz writes about the "ref/val notation for the types":

"Inline" is a way of saying "identity free" when declaring classes, but it doesn't say anything (yet) about the semantics of how we represent variables on the heap or pass them on the stack. For this, we need an additional property of the type, and ref vs val seems to ideally describe what we mean."

Amber Records

In the post "[records] Summary so far," Gavin Bierman writes about "some remaining design decisions concerning records." This post outlines the following questions/design decisions and then provides partial or complete answers to the design decisions (see the post for the additional details related to each design decision).

1. Q1. Should the distinguished supertype of records java.lang.Record be renamed?
2. Q2. Accessibility of mandated members.
3. Q3. Nesting.
4. Q4. Abstract records.
5. Q5. Deconstruction patterns.
6. Q6. @deprecated
7. Q7. .equals and .toString are slow.
8. Q8. Translation strategy.
9. Q9. Hashing.
10. Q10. Special annotation for explicit declaration of accessors.
11. Q11. Changing the spec of .toString method
12. Q12. Transactional methods
13. Q13. Factory methods instead of constructors.

Although Records are available as a preview feature in JDK 14, it's obvious much work is still being done on them. This preview status provides an opportunity for Records to be used and tested to gain feedback that can change how they are implemented. The thirteen design decisions listed above (some of which are decidedly no change and some which are possible changes) demonstrate that Records are still going to be fine-tuned.

JDK 14/JEP 305 instanceof Pattern Matching "Smart Casts"

I generally view the presence of of the instanceof operator in Java code as a "red flag," meaning that it's not necessarily wrong to use instanceof in certain situations, but its use sometimes indicates a design issue that could be resolved in a cleaner way as described in some resources referenced at the end of this post (including resources about similar type checking functionality in languages other than Java).

Although I've seen instanceof used several times when it does not need to be, I've run into even more situations where it was not easy to avoid instanceof. This is particularly true when working with legacy code bases and certain libraries and frameworks in which I have no ability to refactor relationships between classes to support interfaces, method overriding, and other tactics that can be used to remove the need for instanceof.

A very common technique employed with instanceof is to immediately cast to the type checked in the conditional using instanceof. JEP 305 ["Pattern Matching for instanceof (Preview)"] provides an example of this common pattern and I've slightly adapted that example here:

if (object instanceof String)
{
    final String string = (String) object;
    // Do something with the 'string' variable typed as String
}

Benji Weber has posted on using reflection and on using lambda expressions to achieve Kotlin-like "instanceof smart casts." Fortunately, JDK 14 and JEP 305 bring built-in language support (albeit preview status) for this approach.

JDK 14 introduces a preview feature that allows the instanceof conditional and associated cast to be implemented completely within the conditional. The effect on the above code example is shown next:

if (object instanceof String string)
{
    // Do something with the 'string' variable typed as String
}

This preview feature is available in the JDK 14 Early Access Builds and I'm using JDK 14 Early Access Build 34 for my examples in this post.

The JEP 305 preview feature in JDK 14 is a small nicety whose advantage is more obvious in lengthy if-then-else conditional statements. The next two code listings provide a comparison of the "old way" of calling instanceof and explicitly casting to the "new preview way" of using instanceof pattern matching.

Traditional instanceof Coupled with Explicit Cast

static void makeAnimalNoises(final Object animal)
{
   if (animal instanceof Dog)
   {
      final Dog dog = (Dog) animal;
      out.println(dog.bark());
   }
   else if (animal instanceof Cat)
   {
      final Cat cat = (Cat) animal;
      out.println(cat.meow());
   }
   else if (animal instanceof Duck)
   {
      final Duck duck = (Duck) animal;
      out.println(duck.quack());
   }
   else if (animal instanceof Horse)
   {
      final Horse horse = (Horse) animal;
      out.println(horse.neigh());
   }
   else if (animal instanceof Cow)
   {
      final Cow cow = (Cow) animal;
      out.println(cow.moo());
   }
   else if (animal instanceof Lion)
   {
      final Lion lion = (Lion) animal;
      out.println(lion.roar());
   }
   else
   {
      out.println("ERROR: Unexpected animal: " + animal);
   }
}

JDK 14/JEP 305 Preview Feature

static void makeAnimalNoises(final Object animal)
{
   if (animal instanceof Dog dog)
   {
      out.println(dog.bark());
   }
   else if (animal instanceof Cat cat)
   {
      out.println(cat.meow());
   }
   else if (animal instanceof Duck duck)
   {
      out.println(duck.quack());
   }
   else if (animal instanceof Horse horse)
   {
      out.println(horse.neigh());
   }
   else if (animal instanceof Cow cow)
   {
      out.println(cow.moo());
   }
   else if (animal instanceof Lion lion)
   {
      out.println(lion.roar());
   }
   else
   {
      out.println("ERROR: Unexpected animal: " + animal);
   }
}

The full code is on GitHub and the difference between the old approach and new preview approach is available.

Because instanceof pattern matching is a preview feature, the code using this feature must be compiled with the javac flags --enable-preview and -source 14. It must be executed with java flag --enable-preview.

Conclusion

For more details on how this feature is implemented, see the post "RFR: JDK-8237528: Inefficient compilation of Pattern Matching for instanceof." Pattern matching support for instanceof is another Amber-provided step toward reduced boilerplate code in Java.

 

Resources on Issues Using instanceof

• Java 'instanceOf': Why And How To Avoid It In Code
• Do you really need instanceof?
• Is using instanceof in Java consider bad practice?
• Using Instanceof Is Mostly a Code Smell
• Instanceof in Conditionals: A Code Smell
• Beware of instanceof Operator
• How Evil is 'instanceof'?
• Type check is a code smell

Source Code for Effective Java Third Edition Updated to Use Newer Features

Those who have read the Third Edition of Effective Java are likely aware of the source code associated with that book available on GitHub. The jbloch/effective-java-3e-source-code project has 1700+ stars and has been forked nearly 800 times as of this writing. The version of Java featured in the Third Edition of Effective Java is largely JDK 8 with some coverage of JDK 9 (see my earlier post for details on what is covered in this third edition).

Much has been added to the JDK since the publication of the Third Edition of Effective Java and many new releases have arrived with the faster 6-month cadence. Given this, I was particularly interested to see in an amber-spec-experts mailing list post that Rémi Forax has forked jbloch/effective-java-3e-source-code into the GitHub project forax/effective-java-3e-source-code that has "taken the source of Effective Java (3rd Ed) and change them to use var, switch expression, records and the instanceof with the type test pattern."

There are several things that I like about the idea of refreshing examples from Effective Java (Third Edition) to use newer features:

• Developers can see how to apply effective Java practices using recently released features.
• Developers can view the differences between the JDK 8/9 versions and the newer versions to see how new constructs replace older constructs and thus gain a better understanding of the newer constructs.
• It is useful to see some of the changes when deciding whether a particular change to use a newer construct really helps with code readability in a given situation.

The main page for the forked forax/effective-java-3e-source-code (README.md) states, "The source code have been updated to use new constructs available since Java 9, the version used by the 3rd edition." That page then provides bullets on the types of new constructs applied to the source code with links to each new construct's associated JDK Enhancement Proposal (JEP).

As of this writing, Commit 275eef87e4661f7f1edc41f4730cecf7a1096a97 is the main commit of interest. It covers changes to 113 files. I'll call out a few specific changes here to illustrate the types of changes applied (some of which are to apply preferred constructs that were available even before JDK 9):

• NutritionFacts.java (Chapter 2, Item 2) changed from a class to a record.
• PickTwo.java (Chapter 5, Item 32) change demonstrates switch expressions.
• CaseInsenstiveString.java (Chapter 3, Item 10) change demonstrates application of instanceof with type test pattern.
• WordList.java (Chapter 3, Item 14) changed to apply var for variable declarations taking advantage of local type inference. There are many of these changes, but this is one I liked. I'm not convinced that some of the changes in other places (such as changing int to var) are helpful. The change for InstrumentedSet (Chapter 4 Item 18) is even more compelling.
• Change to RecursiveTypeBound.java (Chapter 5, Item 31) demonstrates using var in for loop.
• Copy.copy method (Chapter 2, Item 9) changed to accept instances of Path instead of instances of String and changed to use Files.newInputStream and Files.newOutputStream in place of new FileInputStream and new FileOutputStream respectively.

Conclusion

The ability to view changes to the original source code associated with the Third Edition of Effective Java to accommodate new language constructs is highly useful in terms of learning about the new constructs and how they relate to or replace old constructs and in deciding if the differences are desirable in different situations.

Sealed Types: JLS Changes (Draft)

Following the recent announcement of the candidate JEP on sealed types (preview), Gavin Bierman's message "Draft JLS spec for sealed types" on the OpenJDK amber-spec-experts mailing list announces "a draft language spec for sealed types" and provides a link to that draft. That message also states, "This spec doesn’t yet contain details on binary compatibility (Chapter 13) - to appear in the next draft."

In this post, I highlight some of the proposed changes to the Java Language Specification (JLS) for sealed types. It is important to keep in mind the tentativeness of these proposed changes: this is a draft of proposed JLS changes for a preview feature associated with a candidate JDK Enhancement Proposal (JEP).

With the caveats just outlined in mind, here are some of the interesting currently proposed changes to the JLS for sealed types with new text, deleted text, and typos highlighted differently.

• Chapter 8: Classes
  • New sentences: "The degree to which a class can be extended can be explictly controlled. A class may be declared sealed, in which case there is a fixed set of classes that directly extend the sealed class."
  • Two new class modifiers spelled out in Section 8.1.1 ("Class Modifiers"): "abstract static sealed non-sealed final strictfp"
  • New sentence in Section 8.1.1: "It is a compile-time error if a class declaration has more than one of the class modifiers sealed, non-sealed and final."
  • Title of Section 8.1.1.2 changes to "sealed, non-sealed, and final Classes"
  • Three new sentences in renamed Section 8.1.1.2:
    • "A class can be declared sealed when it is useful to restrict its subclasses to a fixed set of classes."
    • "In certain circumstances, a class can be declared non-sealed to allow unrestricted subclasses."
    • "It is a compile-time error if a class that does not extend a sealed class or implement a sealed interface is declared non-sealed."
  • The entire section 8.1.6 ("Permitted subclasses") is new [former Section 8.1.6 is proposed to be Section 8.1.7] and here are just a few of its sentences:
    • "A sealed class can restrict its subclasses to a fixed set of classes. The permitted subclasses of a sealed class C are declared in a permits clause. A sealed class C may have an explicitly declared permits clause, which provides a non-empty list of the permitted subclasses of C."
    • "It is a compile-time error if a class is declared both abstract and sealed, and has no permitted subclasses, because the implementation of such a class could never be completed."
    • "It is a compile-time error if a class that is not sealed has a permits clause."
• Chapter 9: Interfaces
  • New sentence: "Unlike a class, an interface cannot be declared final. However, an interface may be declared sealed, in which case it specifies a fixed set of classes and interfaces that directly implement or extend the sealed interface."
  • Two new interface modifiers spelled out in Section 9.1.1 ("Interface Modifiers"): "abstract static sealed non-sealed strictfp"
  • Section 9.1.1.3 is proposed as a new section called "sealed and non-sealed Interfaces". It has several new sentences, a subset of which are shown here.
    • "An interface can be declared sealed when it is useful to restrict its subtypes to a fixed set of classes and interfaces."
    • "It is a compile-time error if an interface that does not extend a sealed interface is declared non-sealed."
  • There is a new Section 9.1.4 (the old Section 9.1.4 is proposed to be changed to Section 9.1.5) called "Permitted Subtypes" and here is a subset of sentences in this section.
    • "It is a compile-time error if a sealed interface has no permitted subtypes."
    • "It is a compile-time error if an interface declaration has an explicit permits clause but is not sealed."
    • "If a sealed interface I does not have an explicit permits clause, then it has an implicitly declared permits clause that lists as permitted subtypes all the classes and interfaces in the same compilation unit as I that declare I as their direct superinterface."

There are additional details of sealed types discussed in this draft JLS document that are not highlighted here. In particular, the proposed draft JLS changes specify handling of sealed classes, sealed interfaces, and permitted types within Java modules. In short, it's a compile-time error to have any class designated as permitted for a sealed class or sealed interface that is not in the same module as the sealed class or sealed interface.

The JEP for the sealed types preview feature and the proposed JLS changes for the sealed types preview are both currently in "candidate"/"draft" form, but it's encouraging to see progress being made in the area of sealed types. It will be interesting to see the forthcoming language specification changes related to binary compatibility.

Candidate JEPs: Records and Sealed Types

Mark Reinhold announced two new closely related candidate JDK Enhancement Proposals (JEPs) on the OpenJDK amber-dev mailing list this week with the posts "New candidate JEP: 359: Records (Preview)" and "New candidate JEP: 360: Sealed Types (Preview)." Both of these candidate JEPs are "preview features" (defined by JEP 12).

JEP 359: Records (Preview)

The JEP 359 "Summary" states, "Enhance the Java programming language with records. Records provide a compact syntax for declaring classes which are transparent holders for shallowly immutable data."

The "Motivations and Goals" section of JEP 359 explains how records would benefit Java developers. That section begins by stating that "it is a common complaint that 'Java is too verbose' or has too much 'ceremony" and explaining that "some of the worst offenders are classes that are nothing more than plain 'data carriers' that serve as simple aggregates." This section also states that records are intended to be more than mere "boilerplate reduction" and that they "should be easy, clear, and concise to declare shallowly-immutable, well-behaved nominal data aggregates." In short, the stated driving goal of JEP 359 is to "model data as data."

The recently proposed java.lang.Record draft specification provides significant insight into the characteristics of records. The opening paragraph of the "Description" section of JEP 359 also describes records: "Records are a new kind of type declaration in the Java language. Like an enum, a record is a restricted form of class. It declares its representation, and commits to an API that matches that representation. Records give up a freedom that classes usually enjoy: the ability to decouple API from representation. In return, records gain a significant degree of concision." There is significantly more text in the "Description" section of JEP 359.

JEP 360: Sealed Types (Preview)

The "Summary" section of JEP 360 states, "Enhance the Java programming language with sealed types. Sealed types are classes or interfaces that impose restrictions on which other classes or interfaces may extend or implement them."

The "Goals" section of JEP 360 is also concise, "Enable classes and interfaces to limit permitted subtypes to an enumerated set of types in the same maintenance domain as the type itself."

It is the "Description" section of JEP 360 that provides concreteness to JEP 360. That section begins, "A sealed type is one for which subtyping is restricted according to guidance specified with the type's declaration." The second paragraph of the "Description" section states that "sealing serves two distinct purposes" and describes those purposes:

1. "Restricts which classes may be a subclass of a sealed class."
2. "Potentially enables exhaustiveness analysis at the use site, such as when switching over type patterns for an instance of a sealed type."

There are other interesting characteristics of sealed types described in the "Description" section. Some of these that stood out to me are:

• Use (with example) of the sealed modifier and permits clause.
• "Abstract subtypes of sealed types are implicitly sealed, unless declared with the non-sealed modifier."
• "Concrete subtypes of sealed types are implicitly final, unless declared with the non-sealed modifier."
• "Sealing, like finality, is enforced by both the language compiler and by the JVM. The sealed-ness of a type, and its list of permitted subtypes, are reified in the class file and enforced at runtime."

Other interesting details related to sealed types that are covered in this JEP include restrictions (compiler errors that can occur), the class form for sealed types, and addition of reflection methods to support sealed types.

Conclusion

JEP 359 (Records Preview) and JEP 360 (Sealed Types Preview) reference each other in their documentation. Of the relationship between these two candidate JEPs, JEP 360 states, "Sealed types and records, taken together, form a construct often referred to as algebraic data types." Records and sealed types are key pieces in the move toward Java support for pattern matching.

java.lang.Record: Draft Specification

Work on proposed Java Records continues to proceed. Brian Goetz started three new threads on the OpenJDK amber-spec-experts mailing list yesterday and two of them are focused on Java Records. One of these two Record-oriented threads discusses whether Java records should support varargs. The other thread provides the initial draft specification for the proposed class java.lang.Record and that is the subject of this post.

The first sentence of the proposed class-level Javadoc for java.lang.Record currently says of this class, "This is the common base class of all Java language record classes." This initial specification also shows java.lang.Record being designated as a public abstract class.

Three "common" public abstract methods are explicitly declared in this initial specification of java.lang.Record: equals(Object), hashCode(), and toString(). All three methods are annotated with @Override and documented with {@inheritDoc} with Record specialization details. The specializations of the Javadoc for each of the three methods include Record-specific implementation notes using the @implNote tag. The class-level Javadoc tells us that these three "common" methods can be implicitly created: "The implicit declaration of the equals(Object), hashCode(), and toString() methods are derived from all of the component fields."

The proposed class-level Javadoc currently states, "A record class is a shallowly immutable, transparent carrier for a fixed set of values, called the record components." It also describes a "component field" as "a private static field corresponding to each component, whose name and type are the same as that of the component." The Javadoc states that these component fields are mandatory and adds that "a public accessor method corresponding to each component, whose name and return type are the same as that of the component" is also required. Further, the Javadoc adds that "implicit implementations for these members are provided" if none is expressed explicitly.

The proposed Javadoc also explains when one might choose to explicitly specify the Record constructor or accessor methods: "The primary reasons to provide an explicit declaration for the canonical constructor or accessor methods are to validate constructor arguments, perform defensive copies on mutable components, or normalize groups of components."

The draft specification for java.lang.Record adds concreteness to discussions regarding the implementation and use of Java Records. The proposed specification has already generated discussion on the amber-spec-experts mailing list. Topics discussed in relation to this specification include whether Records should prohibit cloning, whether to mention boxing of primitives in the equals method Javadoc, and whether Record.toString() and Enum.toString() should have warnings added to their Javadoc regarding changed output when a field is renamed.

The presentation of and discussion of a specification for java.lang.Record has heightened my anticipation for this feature from Project Amber.

Additional Resources

• Draft specification for java.lang.Record
• Draft JEP: Records for the Java Language (Preview)
• April 2019 Update on Java Records
• Updates on Records (Data Classes for Java) (April 2018)

Java Text Blocks

In the 13 May 2019 post "RFR: Multi-line String Literal (Preview) JEP [EG Draft]" on the OpenJDK amber-spec-experts mailing list, Jim Laskey announced a draft feature JEP named "Text Blocks (Preview)" (JDK-8222530).

Laskey's post opens with (I've added the links), "After some significant tweaks, reopening the JEP for review" and he is referring to the draft JEP that was started after the closing/withdrawing of JEP 326 ["Raw String Literals (Preview)"] (JDK-8196004). Laskey explains the most recent change to the draft JEP, "The most significant change is the renaming to Text Blocks (I'm sure it will devolve over time Text Literals or just Texts.) This is primarily to reflect the two-dimensionality of the new literal, whereas String literals are one-dimensional." This post-"raw string literals" draft JEP previously referred to "multi-line string literals" and now refers to "text blocks."

The draft JEP "Text Blocks (Preview)" provides detailed overview of the proposed preview feature. Its "Summary" section states:

Add text blocks to the Java language. A text block is a multi-line string literal that avoids the need for most escape sequences, automatically formats the string in predictable ways, and gives the developer control over format when desired. This will be a preview language feature.

This is a follow-on effort to explorations begun in JEP 326, Raw String Literals (Preview).

The draft JEP currently lists three "Goals" of the JEP and I've reproduced the first two here:

1. "Simplify the task of writing Java programs by making it easy to express strings that span several lines of source code, while avoiding escape sequences in common cases."
2. "Enhance the readability of strings in Java programs that denote code written in non-Java languages."

The "Non-Goals" of this draft JEP are also interesting and the two current non-goals are reproduced here:

1. "It is not a goal to define a new reference type (distinct from java.lang.String) for the strings expressed by any new construct."
2. "It is not a goal to define new operators (distinct from +) that take String operands."

The current "Description" of the draft JEP states:

A text block is a new kind of literal in the Java language. It may be used to denote a string anywhere that a string literal may be used, but offers greater expressiveness and less accidental complexity.

A text block consists of zero or more content characters, enclosed by opening and closing delimiters.

The draft JEP describes use of "fat delimiters" ("three double quote characters": ===) in the opening delimiter and closing delimiter that mark the beginning and ending of a "text block." As currently proposed, the text block actually begins on the line following the line terminator of the line with the opening delimiter (which might include spaces). The content of the text block ends with the final character before the closing delimiter.

The draft JEP describes "text block" treatment of some special characters. It states, 'The content may include " characters directly, unlike the characters in a string literal.' It also states that \" and \n are "permitted, but not necessary or recommended" in a text block. There is a section of this draft JEP that shows examples of "ill-formed text blocks."

There are numerous implementation details covered in the draft JEP. These include "compile-time processing" of line terminators ("normalized" to "to LF (\u000A)"), incidental white space (differentiation of "incidental white space from essential white space" and use of String::indent for custom indentation management), and escape sequences ("any escape sequences in the content are interpreted" per Java Language Specification and use of String::translateEscapes for custom escape processing).

Newly named "Java Text Blocks" look well-suited for the stated goals and the current proposal is the result of significant engineering effort. The draft JEP is approachable and worth reading for many details I did not cover here. Because this is still a draft JEP, it has not been proposed as a candidate JEP yet and has not been targeted to any specific Java release.

A New Era for Determining Equivalence in Java?

Liam Miller-Cushon has published a document simply called "Equivalence" in which he proposes "to create a library solution to help produce readable, correct, and performant implementations of equals() and hashCode()." In this post, I summarize some reasons why I believe this proposal is worth reading for most Java developers even if the proposal never gets implemented and why the proposal's implementation would benefit all Java developers if realized.

Miller-Cushon opens his proposal with a single-sentence paragraph: "Correctly implementing equals() and hashCode() requires too much ceremony." The proposal points out that today's powerful Java IDEs do a nice job of generating these methods, but that there is still code to be read and maintained. The proposal also mentions that "over time these methods become a place for bugs to hide." I have been on the wrong end more than once of particularly insidious bugs caused by an error in one of these methods and these can be tricky to detect.

All three editions of "Effective Java" provide detailed explanation and examples for how to write effective implementations of these methods, but it's still easy to get them wrong. The JDK 7 (Project Coin)-introduced methods Objects.equals(Object, Object) and Objects.hash(Object...) have helped considerably (especially in terms of readability and dealing with nulls properly), but there are still errors made in implementations of Object.equals(Object) and Object.hashCode().

Even if this "Equivalence" proposal never comes to fruition, there is some value in reading Miller-Cushon's document. One obvious benefit of this document is its capturing of "Examples of bugs in equals and hashCode implementations." There are currently nine bullets in this section describing the "wide array of bugs in implementations of equals and hashCode methods" that were often identified only when "static analysis to prevent these issues" was performed. These examples serve as a good reminder of the things to be careful about when writing implementations of these methods and also reminds us of the value of static analysis (note that Miller-Cushon is behind the static analysis tool error-prone).

Reading of the "Equivalence" document can also be enlightening for those wanting to better understand the related issues one should think about when developing the equivalence concept in Java. Through sets of questions in the "Requirements" and "Design Questions" sections, the document considers trade-offs and implementation choices that would need to be made. These cover topics such as how to handle nulls, instanceof versus getClass(), and the relationship to Comparator. Many of these considerations should probably be made today by Java developers implementing or maintaining their own implementations of equals(Object) and hashCode().

The "Related reading" section of the "Equivalence" document provides links to some interesting reading that includes the 2009 classic article "How to Write an Equality Method in Java" and Rémi Forax's ObjectSupport class (which delegates to ObjectSupports in some cases).

The "Equivalence" proposal was presented on the OpenJDK amber-spec-experts mailing list in a post title "A library for implementing equals and hashCode" and some of the feedback on that mailing list has led to updates to the document. One particularly interesting sentence for me in this discussion is Brian Goetz's statement, "That people routinely implement equals/hashCode explicitly is something we would like to put in the past." That seems like a welcome change!

OpenJDK on GitHub

Project Skara was created "to ... investigate alternative SCM and code review options for the JDK source code, including options based upon Git rather than Mercurial, and including options hosted by third parties." The OpenJDK skara-dev mailing list included a post from Robin Westberg last week that announced, "We have added some additional read-only mirrors of a few different OpenJDK project repositories to the https://github.com/openjdk group..."

The read only OpenJDK repositories on GitHub will likely be more convenient for developers wanting to take advantage of the "open source" nature of OpenJDK to take a peek at its internals. More developers are likely to be comfortable with Git than with Mercurial. The GitHub-hosted repositories make it even easier to clone a given repository or to even fork it.

As of this writing, there are currently nine public repositories hosted on the OpenJDK GitHub site:

• Current/JDK 13: openjdk/jdk
  • Mirror of https://hg.openjdk.java.net/jdk/jdk
• JDK 12 Updates: openjdk/jdk12u
  • Mirror of https://hg.openjdk.java.net/jdk-updates/jdk12u/
• Client Libraries: openjdk/client
  • Mirror of https://hg.openjdk.java.net/jdk/client/
• Project Amber: openjdk/amber
  • Mirror of https://hg.openjdk.java.net/amber/amber/
• Project Valhalla: openjdk/valhalla
  • Mirror of https://hg.openjdk.java.net/valhalla/valhalla/
• Project Panama: openjdk/panama
  • Mirror of https://hg.openjdk.java.net/panama/dev/
• Project Loom: openjdk/loom
  • Mirror of https://hg.openjdk.java.net/loom/loom/
• Project Metropolis: openjdk/metropolis
  • Mirror of https://hg.openjdk.java.net/metropolis/dev/
• Project Portola: openjdk/portola
  • Mirror of https://hg.openjdk.java.net/portola/portola/

This is not the first time the OpenJDK has been mirrored on GitHub. There are 11 repositories in "Mirror of OpenJDK repositories": jdk (2017), jdk7u-jdk (2012), jdk7u (2012), openjdk-mirror-meta (2015), corba (2015), jaxp (2015), jdk7u-langtools (2012), jdk7u-jaxws (2012), jdk7u-jaxp (2012), jdk7u-hotspot (2012), and jdk7u-corba (2012). There is also a Project-Skara/jdk that was last updated in August 2018.

Project Skara is not finished and active development of OpenJDK continues on the Mercurial-based version control system. However, the availability of important OpenJDK repositories on GitHub should make it more convenient for Java developers to analyze OpenJDK source code.

April 2019 Update on Java Records

After Project Valhalla's "Value Types/Objects", the language feature I am perhaps the most excited to see come to Java is Project Amber's "Data Classes" (AKA "Records"). I wrote the post "Updates on Records (Data Classes for Java)" about this time last year and use this post to provide an update on my understanding of where the "records" proposal is now.

A good starting point for the current state of the "records" design work is Brian Goetz's February 2019 version of "Data Classes and Sealed Types for Java." In addition to providing background on the usefulness of "plain data carriers" being implemented with less overhead than with traditional Java classes and summarizing design decisions related to achieving that goal, this post also introduces noted Java developer personas Algebraic Annie, Boilerplate Billy, JavaBean Jerry, POJO Patty, Tuple Tommy, and Values Victor.

Here are some key observations that Goetz makes in the "Data Classes and Sealed Types for Java" document.

• "Java asks all classes ... to pay equally for the cost of encapsulation -- but not all classes benefit equally from it."
• Because "the cost of establishing and defending these boundaries ... is constant across classes, but the benefit is not, the cost may sometimes be out of line with the benefit."
• "This is what Java developers mean by too much ceremony' -- not that the ceremony has no value, but that they're forced to invoke it even when it does not offer sufficient value."
• "The encapsulation model that Java provides -- where the representation is entirely decoupled from construction, state access, and equality -- is just more than many classes need."
• "... we prefer to start with a semantic goal: modeling data as data."
• "The API for a data class models the state, the whole state, and nothing but the state. One consequence of this is that data classes are transparent; they give up their data freely to all requestors."
• "We propose to surface data classes in the form of records; like an enum, a record is a restricted form of class. It declares its representation, and commits to an API that matches that representation. We pair this with another abstraction, sealed types, which can assert control over which other types may be its subclasses."
• "Records use the same tactic as enums for aligning the boilerplate-to-information ratio: offer a constrained version of a more general feature that enables standard members to be derived. ... For records, we make a similar trade; we give up the flexibility to decouple the classes API from its state description, in return for getting a highly streamlined declaration (and more)."
• Restrictions on currently proposed records include: "record fields cannot be mutable; no fields other than those in the state description are permitted; and records cannot extend other types or be extended."
• "... an approach that is focused exclusively on boilerplate reduction for arbitrary code is guaranteed to merely create a new kind of boilerplate."
• "...records are not intended to replace JavaBeans, or other mutable aggregates..."

One section of Goetz's post provides an overview of likely use cases for records. These usage cases (which include descriptions in the Goetz post) include multiple return values (something that Java developers seem to frequently use custom or library-provided tuples for), Data Transfer Objects (DTOs), compound map keys, messages, and value wrappers.

Goetz specifically addresses the question related to the records proposal, "Why not 'just' do tuples?" Goetz answers his own question with multiple reasons for using the data class/record concept rather than simply adding tuples to Java. I'm generally not a fan of tuples because I think they reduce the readability of Java code and, especially if the values in the tuple have the same data type, can lead to subtle errors. Goetz articulates similar thinking, "Classes and class members have meaningful names; tuples and tuple components do not. A central aspect of Java's philosophy is that names matter; a Person with properties firstName and lastName is clearer and safer than a tuple of String and String." I prefer getFirstName() and getLastName() to getLeft() and getRight() or to getX() and getY(), so this resonates with me.

Another section of the Goetz document that I want to emphasize is the section headlined "Are records the same as value types?" This section compares Project Valhalla's value types to Project Amber's data classes. Goetz writes, "Value types are primarily about enabling flat and dense layout of objects in memory. In exchange for giving up object identity ..., the runtime gains the ability to optimize the heap layout and calling conventions for values. With records, in exchange for giving up the ability to decouple a classes API from its representation, we gain a number of notational and semantic benefits. ... some values may still benefit from state encapsulation, and some records may still benefit from identity, so they are not the exact same trade."

There has been more discussion on the amber-spec-experts mailing list this week regarding what to call "data classes." Naming is important and notoriously difficult in software development and I appreciate this discussion because the arguments for various names have helped me to understand what the current thinking is about what "data classes" are currently envisioned to be and not to be. Here are some excerpts from this enlightening thread:

• Rémi Forax likes "named tuples" because data classes are immutable and have some commonality with "nominal tuples."
• Brian Goetz likes starting with "records are just nominal tuples" to "avoid picking that fight" between different groups of people with "two categories of preconceived notions" of what a tuple is.
• Kevin Bourrillion adds, "Records have semantics, which makes them 'worlds' different from tuples. ... I think it's fair to say that all a record 'holds' is a 'tuple', but it's so much more. Record is to tuple as enum is to int."
• Guy Steele adds, "Java `record` is to C `struct` as Java `enum` is to C `enum`."

I continue looking forward to getting "data classes" in Java at some point in the future and appreciate the effort being put into ensuring their successful adoption when added. When transitioning from C++ to Java, I missed the enum greatly, but the wait was worth it when Java introduced its own (more powerful and safer) enum. I hope for a similar feeling about Java data classes/records when we get to start using them.

Proposal for Wider Range of Available Java Keywords

In the recent posts titled "We need more keywords, captain!" on the OpenJDK amber-spec-experts mailing list, Brian Goetz "proposes a possible move that will buy us some breathing room in the perpetual problem where the keyword-management tail wags the programming-model dog." His proposal is to "allow _hyphenated_ keywords where one or more of the terms are already keywords or reserved identifiers."

Goetz points out in the original post that Section 3.9 ("Keywords") of the Java Language Specification spells out the current keywords in Java and that these chosen keywords have been stable since Java's inception with the only changes being the addition of the highlighted keywords shown below (assert in JDK 1.4, enum in JDK 1.5, and _ in JDK 1.9):

abstract   continue   for          new         switch
assert     default    if           package     synchronized
boolean    do         goto         private     this
break      double     implements   protected   throw
byte       else       import       public      throws
case       enum       instanceof   return      transient
catch      extends    int          short       try
char       final      interface    static      void
class      finally    long         strictfp    volatile
const      float      native       super       while
_ (underscore)

Goetz's post writes about "several tools at our disposal" that have been or could be used when the set of pre-established keywords are not "suitable for expressing all the things we might ever want our language to express." Goetz emphasizes this point, "The lack of reasonable options for extending the syntax of the language threatens to become a significant impediment to language evolution."

Goetz provides significant background explanation regarding the downsides of the "several tools" he had mentioned earlier in the post and states, "We need a new source of keyword candidates." Goetz then proposes to "allow _hyphenated_ keywords where one or more of the terms are already keywords or reserved identifiers."

The Goetz post provides several examples to illustrate hyphenated keywords and how they might be used. Goetz emphasizes that this list is not in any way proposing these specific keywords for now, but is only providing them as illustrative examples. See the original post for brief descriptions of how some of these illustrative examples might be used.

• non-null
• non-final
• package-private
• public-read
• null-checked
• type-static
• default-value
• eventually-final
• semi-final
• exhaustive-switch
• enum-class
• annotation-class
• record-class
• this-class
• this-return

Two other posts on the mailing list have already built on this original message. In a reply to his own message, Goetz writes that the expression switch could have (or still might be able to because switch expressions are currently a Preview Feature) support a keyword such as break-with rather than requiring developers to "disambiguate whether [a given break is a] labeled break or a value break." Guy Steele replied that he prefers break-return to break-with and that this particular single illustrative example "has [maybe] won me over to the idea of hyphenated keywords."

The Goetz post "We need more keywords, captain!" has seen some attention on Twitter as well. Sander Mak tweeted, "Another example of real-world programming language design by @BrianGoetz: http://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-January/000945.html ... Love the diligence and forward-looking nature of these #Java language design discussions." Bruno Borges tweeted a quote from that same post: "We are convinced that @Java has a long life ahead of it, and developers are excited about new features that enable to them to write more expressive and reliable code."

The hyphenated keyword approach seems promising. Regardless of what happens, the Goetz post makes for an interesting read regarding the difficulty of adding or reapplying keywords to a long-lived programming language concerned about backwards compatibility. The post is also offers a peek into the types of issues, constraints, and trade-offs language designers must make.

Restarting Java's Raw String Literals Discussion

It was announced in December 2018 that raw string literals would be dropped from JDK 12. Now, in the new year, discussion related to the design of raw string literals in Java has begun again.

In the post "Raw string literals -- restarting the discussion" on the amber-spec-experts OpenJDK mailing list, Brian Goetz references the explanation for dropping raw string literals preview feature from JDK 12 and suggests "restart[ing] the design discussion." Goetz summarizes the previous design discussions and decisions and lessons learned from the first take on raw string literals, discusses some design questions and trade-offs to be made, and then calls for input on three specific types of observation data:

• "Data that supports or refutes the claim that our primary use cases are embedded JSON, HTML, XML, and SQL."
• "Use cases we've left out..."
• "Data (either Java or non-Java) on the use of various flavors of strings (raw, multi-line, etc) in real codebases..."

Jim Laskey posted two messages with the title "Enhancing Java String Literals Round 2" to the same amber-spec-experts mailing list and references an HTML version and a PDF version of an "RTL2" document that aids in the discussion of "Take Two" of raw string literals. Laskey outlines a "series of critical decision points that should be given thought, if not answers, before we propose a new design."

A few of the major decisions to be made as raw string literals for Java are reconsidered include these discussed in the aforementioned posts are listed here, but many more are contained in the posts:

• Which is really more important to developers: "raw text" or "multi-line strings"?
• Which character makes for the best delimiter for most Java developers and Java use cases?
• How should incidental spacing be handled?

There has already been some feedback on the amber-dev OpenJDK mailing list. Stephen Colebourne provides "Extended string literals feedback" and Bruno Borges recommends "special assignment rather [than] special delimiters."

I often see developers complaining about certain language and API decisions after the decisions have been implemented. For anyone with strong feelings about the subject of raw string literals and multi-line strings in Java, now is an opportunity to make one's voice heard and to possibly influence the final design that will come to Java at some point in the future. Discussion has also started on the Java subreddit in two threads: "Raw string literals -- restarting the discussion" and "New RSL Proposal".

Dropping Raw String Literals from JDK 12

It has been proposed that raw string literals (preview) be dropped from JDK 12 (which enters Rampdown Phase One on December 13). Brian Goetz has written a detailed description of the motivations for dropping this preview feature (JEP 326). There is also discussion on this on the Java subreddit. In the post "JSR 386 (Java SE 12) JEP Propose to Drop: 326: Raw String Literals (Preview)," Iris Clark writes that JEP 326 "of scope 'SE' has been Proposed to Drop for Java SE 12."

In Goetz's explanation for the proposal to remove raw string literals preview functionality from JDK 12, he writes, "The Preview Feature mechanism is intended for features for which there is a high confidence that the feature is 'done', and the likelihood that significant changes would be made before making the feature permanent is low." Goetz adds, "I am no longer convinced that we've yet got to the right set of tradeoffs between complexity and expressiveness, or that we've explored enough of the design space to be confident that the current design is the best we can do. By withdrawing, we can continue to refine the design, explore more options, and aim for a preview that actually meets the requirements of the Preview Feature process (JEP 12)."

Goetz also provides a sample of the feedback items they've received regarding raw string literals preview design and implementation. He concludes the message with the statement, "Discussion on the technical details of this feature can continue to take place on the amber-* lists" (amber-dev, amber-spec-comments, amber-spec-experts, and amber-spec-observers).

It sounds like there are still plans for raw string literals to come to Java, but they'll be implemented differently than they are currently in JDK 12 Early Access Builds.