Java would gain records and sealed types capabilities as part of a draft JDK enhancement proposal intended to address complaints that Java is too verbose and requires too much “ceremony” code. The proposal was initiated by Brian Goetz, Java language architect at Oracle.
Records provide a compact syntax for declaring classes that are transparent holders for shallowly immutable data. Sealed types, meanwhile, offer a means for declaring classes and interfaces that can restrict their subtypes. Combined, these features are sometimes referred to as algebraic data types.
The time frame for when these features might turn up in Java is uncertain. The official Java Enhancement Proposal (JEP) for records and sealed types in the OpenJDK community does not initially cite a particular release of Java that would be targeted for these capabilities. The next release of standard Java, Java Development Kit (JDK) 13, is due in September.
In explaining the motivation behind records and sealed types, the proposal cites verbosity and ceremony as a common complaint among Java developers, with classes that are nothing more than plain data carriers serving as one of the worst examples. Writing a simple data class properly in Java requires too much low-value, error-prone code such as constructors or accessors, the proposal argues:
IDEs will help you write most of this code, but don’t do anything to help the reader distill the design intent of “I’m a plain data carrier forx,y, andz” from the dozens of lines of boilerplate. Writing Java code that models simple data aggregates should be easier—easier to write, easier to read, and easier to be correct.
Records are a restricted form of class that declares a presentation and commits to an API to match that representation. A sealed type is a type for which subclassing is restricted based on guidance specified with the type’s declaration. The goal of the restrictions inherent in records and sealed types is to gain more clarity and concision. For example, records give up “a degree of freedom” that classes usually enjoy, which is the ability to decouple a class’s API from representation, but gain a significant degree of concision in return. A record is “the state, the whole state, and nothing but the state.”
The proposal does not attempt to declare “war on boilerplate.” It is not a goal to address the problems of mutable classes using JavaBean naming conventions. It also is not a goal of the proposal to add features such as annotation-driven code generation, properties, or metaprogramming, even if they are often seen as “solutions” to the problem.