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)

Draft JEP to Remove Deprecated CMS Garbage Collector

In the 10 April 2017 post "Java Garbage Collectors: When Will G1GC Force CMS Out?," I discussed JEP 291 ("Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector") and provided a summary of some of the feedback for and against deprecating (and ultimately removing) the Concurrent Mark Sweep (CMS) Garbage Collector (GC). Earlier this month, a draft JEP called "Remove the Concurrent Mark Sweep Garbage Collector" was created.

The "Summary" section of this draft JEP states, "Remove the Concurrent Mark Sweep (CMS) garbage collector from the set of usable garbage collection algorithms." Although the "draft" status of this JEP means it's not targeted to any specific release, the "Non-Goals" section reassures us that the draft JEP is not intended to remove CMS from any releases prior to the release in which CMS is removed. The post "RFC: JEP: Remove the Concurrent Mark Sweep Garbage Collector" states that the current plan is to target CMS removal for JDK 14.

The draft JEP states in the "Risks and Assumptions" section that this draft to remove CMS GC "might be withdrawn" if another "interested credible contributor in the community will step up for maintenance." However, in the 2+ years since JEP 291 deprecated CMS, no such "interested credible contributor" has offered to maintain CMS. Thomas Schatzl's post related to this JEP describes this better:

There has also always been the option to organize maintenance of CMS in the community, but nobody even stepped up starting to fix the long-standing existing known minor issues CMS (to get contributors to know CMS code and to give us confidence that these persons can take over maintenance of such a large component).

The draft JEP for removing CMS specifically mentions three recommend alternative garbage collectors: the now-default garbage-first (G1), Oracle-provided ZGC, and Red Hat-provided Shenandoah.

There were multiple objections to deprecating CMS when JEP 291 was under review and there are objections now to the idea of removing CMS altogether. Kirk Pepperdine has written that he and others have observed that "CMS overheads are no where near the level of those seen with G1" and they are "now recommending that customers consider Parallel GC as it offers a far better experience than G1."

It looks likely that CMS will be removed as a garbage collection option in a forthcoming JDK release (perhaps even as early as JDK 14). As Kirk Pepperdine expressed in another post on the subject, "At the end of the day, if we want CMS we're going to have to step up and do something about it." So far, it doesn't look like anyone's wanted CMS badly enough to do something about it (which might include working with their preferred JDK provider to have it supported in that provider's JDK).

Project Valhalla Eclairs

Éclairs offer several appealing characteristics and have been described as a "trifecta" that "encompass[es] the trinity of pastry, a light and crispy shell, a silky creamy filling and intense chocolate glaze." In the OpenJDK valhalla-spec-experts mailing list, Brian Goetz's post "Collapsing the requirements" proposes the concept of Valhalla "Eclairs" and discusses how use of these "eclairs" in Valhalla can provide their own trifecta of removing the need for LV in the VM ("LPoint/QPoint distinction" or boxed projection versus unboxed projection or "LV is the null-adjunction of QV"), removing the need for V? in the language, and removing the need for null default values.

Goetz's "Summary" in the "Collapsing the requirements" summarizes the value of the proposed Valhalla eclairs and succinctly states what the proposed "eclairs" concept is (I have added the emphasis), "In one swoop, we can banish LV from the VM, V? from the language, and null-default values, by making a simple requirement: every value type is paired with an interface or abstract class 'box'. For most values, this can be automatically generated by the compiler and denoted via a well-known name (e.g., V.Box); for some values, such as those that are migrated from reference types, we can explicitly declare the box type and pick explicit names for both types."

Goetz provides more details and examples in the "Collapsing the requirements" post of "requiring that every value type have a companion interface (or abstract class) supertype." He also provides a more formal definition:

Define an envelope-class pair ("eclair") as a pair (V, I) such that:

• V is an inline class
• I is a sealed type
• I permits V (and only V)
• V <: I

Several other Goetz statements in the "Collapsing the requirements" post highlight desirable features of these proposed Valhalla eclairs and here is a sample:

• "If every value type be a member of an eclair, we can use V when we want the flattenable, non-nullable, specializable type; and we use I when we want the non-flattenable, nullable, erased 'box'. We don’t need to denote `V?`; we can just use I, which is an ordinary, nominal type."
• "Now, the type formerly known as `V?` is an ordinary, nominal interface (or abstract class) type. The user can say what they mean, and no magic is needed by either the language or the VM."
• "Using the eclair wrapper also kicks the problem of erased generics down the road; if we use `Foo<I>` for erased generics, and temporarily ban `Foo<V>`, when we get to specialized generics, it will be obvious what `Foo<V>` means (their common super type will be `Foo<? extends I>`). This is a less confusing world, as then 'List of erased V' and 'List of specialized V' don’t coexist; there’s only 'List of V' and 'List of V’s Box'."

One last aspect of the "Collapsing the requirements" post that I want to highlight here is the proposal to "define a new public value class `Opt<T>` which is the value half of the eclair, and the existing Optional is the interface/abstract class half." Goetz explains that the new value class Opt is needed as a compromise (rather than adapting existing reference class Optional to be the inside of the eclair) because "existing variables of type Optional are not flattened" when today's Optional is migrated to an eclair.

Although it is a bit of a compromise to have to know, use, and differentiate another type Opt from Optional, one of the advantages of having Opt be the value portion of the eclair and having Optional be the interface/supertype portion of the eclair (and the support of boxing conversion between them) is that there is a relatively straightforward migration path between today's use of Optional and tomorrow's use of Opt. As Goetz puts it, "existing fields / arrays can migrate gradually to Opt, as they want the benefit of flattening; existing APIs can continue to truck in Optional." Goetz summarizes the migration benefit and cost of the Opt approach: "Users can migrate their fields gradually. The cost: the good name gets burned. But there is a compatible migration path from ref to value."

It's a bit disappointing to need to use "Opt" instead of "Optional", but I think most Java developers could quickly become used to applying Opt when it's available and its advantages are identified. Today's powerful Java IDEs could also identify places where existing Optional usage can be changed to Opt and warn the developer when he or she tried to introduce an Optional reference class when an Opt value class could be used.

Eclairs are tasty, tempting treats and the proposed Valhalla "eclairs" have some tempting characteristics of their own.