Friday, December 20, 2019

General, Safe, and Deterministic Foreign Memory Access in JDK 14

In the post "JDK 14 Rampdown: Build 27," I summarized the numerous JDK 14-targeted features newly available with JDK 14 Early Access Build #27. There is already another JDK 14 Early Access Build available and this one [Build 28 (2019/12/18)] includes one particularly interesting feature: Enhancement JDK-8234049 ["Implementation of Memory Access API (Incubator)"]. This is the implementation of JEP 370 ["Foreign-Memory Access API (Incubator)"], which is summarized as, "Introduce an API to allow Java programs to safely and efficiently access foreign memory outside of the Java heap."

JEP 370 is intended to achieve a "foreign memory API" that provides "generality", "safety", and "determinism" (with each of these means described in further detail in the JEP). The JEP also states that this foreign memory API is intended as an alternative to currently used approaches (java.nio.ByteBuffer and sun.misc.Unsafe). Downsides and limitations of both of these currently available alternates are discussed in the JEP.

The JEP points out that libraries "access foreign memory" to "avoid the cost and unpredictability associated with garbage collection," to "share memory across multiple processes," and to "serialize and deserialize memory content by mapping files into memory." It adds that "the Java API does not provide a satisfactory solution for accessing foreign memory."

JEP 370's "Description" section introduces the implementation of the foreign memory access API. The section begins, "The foreign-memory access API introduces three main abstractions: MemorySegment, MemoryAddress and MemoryLayout." The section then describes these three main abstractions: "A MemorySegment is used to model a contiguous memory region with given spatial and temporal bounds. A MemoryAddress can be thought of as an offset within a segment. Finally, a MemoryLayout is a programmatic description of a memory segment's contents."

After several detailed examples of using the foreign memory access, the JEP's "Description" section states, "The foreign-memory access API will initially be provided as an incubating module, named jdk.incubator.foreign, in a package of the same name."

Additional background details related to JEP 370 are available in OpenJDK mailing list messages. One key thread starts with the message "RFR JDK-8234049: Implementation of Memory Access API (Incubator)." The CSR for this JEP [JDK-8234050: Implementation of Memory Access API (Incubator)] presents alternate useful descriptions. Javadoc-based documentation for the foreign memory access API is also temporarily available at http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html.

The JEP 370 implementation is included in the JDK 14 Early Access Build #28 and available to try.

Saturday, December 14, 2019

JDK 14 Rampdown: Build 27

Mark Reinhold's recent post "JDK 14 is now in Rampdown Phase One" announced that "we are now in Rampdown Phase One" and that "the overall feature set is frozen." JDK 14 Early Access Build #27 (2019/12/12) is a hefty build. In this post, I summarize some of the changes associated with JDK 14 Early Access Build 27 that are particularly interesting to me.

One might say that JDK 14 Early Access Build 27 is the "records build." This build is full of updates related to the implementation of the records preview feature (JEP 359). Here are some of the changes associated with this "records build" filled with JEP 359 implementation changes (note that there are already bugs written and fixed for records):

  • JEP 359 JDK-8222777: Records (Preview)
  • Sub-Task JDK-8227113: Specification for java.lang.Record
  • Sub-Task JDK-8225053: Preview APIs support for records
  • Sub-Task JDK-8233526: JVM support for records
  • Sub-Task JDK-8225054: Compiler implementation for records
  • Sub-Task JDK-8225057: Java Language Specification changes for Records
  • Sub-Task JDK-8225058: JVM Specification changes for Records
  • Sub-Task JDK-8225055: Javadoc for records
  • Sub-Task JDK-8225052: javax.lang.model support for records
  • Sub-Task JDK-8226314: com.sun.source support for records
  • Enhancement JDK-8235359: Simplify method Class.getRecordComponents()
  • Bug JDK-8235550: Clarify record reflective support specification
  • Bug JDK-8235369: Class.toGenericString need to be updated for records
  • Bug JDK-8235446: confusing error message for records with no parens
  • Bug JDK-8234101: Compilation error thrown when repeating annotation is used on record component
  • Bug JDK-8235474: JShell does not handle records properly

Although JEP 359/Records (Preview) will likely dominate interest of many Java developers in the JDK 14 Early Access Build 27, there are other interesting changes in this build that are summarized here (with links to more details and quotes from the change descriptions):

In addition to the changes that I called out above, other changes associated with JDK 14 Early Access Build 27 include changes to areas that have changes in many JDK 14 builds (Shenandoah garbage collector, Z garbage collector [ZGC], Java Flight Recorder, and the Java packaging tool).

The JDK 14 Early Access Build 27 Release Notes state that "SSLv2Hello and SSLv3 have been removed from the default enabled TLS protocols." The release notes add that "If a client or server still needs to use the SSLv3 protocol they can do so by enabling it via the jdk.tls.client.protocols or jdk.tls.server.protocols system properties or with the SSLSocket.setEnabledProtocols(), SSLServerSocket.setEnabledProtocols() and SSLEngine.setEnabledProtocols() APIs."

I am excited about Records in Java 14 and look forward to playing with them via the OpenJDK 14 Early Access Build 27.

Monday, November 18, 2019

JDK 14: Records, Text Blocks, and More

Today's Mark Reinhold post "JEPs proposed to target JDK 14: 305, 343, 359, 366, & 368" proposes targeting five more JEPs to JDK 14. Some highly anticipated features are among this group, although all but one are proposed to be in "preview" or "incubating":

  • JEP 305: Pattern Matching for instanceof (Preview)
  • JEP 343: Packaging Tool (Incubator)
  • JEP 359: Records (Preview)
  • JEP 366: Deprecate the ParallelScavenge + SerialOld GC Combination
  • JEP 368: Text Blocks (Second Preview)

The Java SE 13 Java Language Updates document describes preview features (JEP 12): "A preview feature is a new feature whose design, specification, and implementation are complete, but which is not permanent, which means that the feature may exist in a different form or not at all in future JDK releases."

JEP 11 ("Incubator Modules") describes "incubator modules" as "a means of putting non-final APIs and non-final tools in the hands of developers, while the APIs/tools progress towards either finalization or removal in a future release."

Four of the five JEPs proposed today for targeting JDK 14 are "preview" or "incubator" and so will be subject to potentially "not exist .... at all in future JDK releases" or potential "removal in a future release." However, the opportunity to take these features for a spin is welcome and there seems likely that these features will eventually become permanent even if they have some modifications. We could have these JEPs officially targeted for JDK 14 by Thanksgiving!

Additional Resources

JDK 14: CMS GC is OBE

JDK 14 Early Access Build #23 (2019/11/13) is now available. One of the more noteworthy changes with this build is the removal of the Concurrent Mark Sweep garbage collector. JEP 291 ["Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector"] deprecated the Concurrent Mark Sweep (CMS) garbage collector back in 2017 with JDK 9 and JEP 363 ["Remove the Concurrent Mark Sweep (CMS) Garbage Collector"] has been targeted for JDK 14 to remove the CMS garbage collector altogether.

The next screen snapshot demonstrates that the CMS garbage collector was still available with JDK 14 Early Access Build #22.

With that JDK 14 Early Access Build #22, we see that specifying -XX:+UseConcMarkSweepGC is allowed with only a deprecation warning shown: "Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release."

The next screen snapshot demonstrates that CMS cannot be specified as a garbage collector as of JDK 14 Early Access Build #23:

When trying to run the Java application with -XX:+UseConcMarkSweepGC, the error message now shown states, "Ignoring option UseConcMarkSweepGC; support was removed in 14.0".

Although the removal of the CMS garbage collector was the biggest change I noticed in JDK 14 Early Access Build #23, there were a few other changes that I found to be somewhat interesting. These include:

Saturday, November 2, 2019

Six More JEPs Proposed for JDK 14

A recent Mark Reinhold message announces six new "JEPs proposed to target JDK 14": JEP 345, JEP 361, JEP 363, JEP 364, JEP 365, and JEP 367. Assuming no objections are made by November 7, these JEPs will be targeted to JDK 14 along with previously targeted JEPs JEP 349 ("JFR Event Streaming"), JEP 352 ("Non-Volatile Mapped Byte Buffers"), and JEP 358 ("Helpful NullPointerExceptions"). This post summarizes each of these six JEPs proposed for targeting JDK 14.

JEP 345: NUMA-Aware Memory Allocation for G1

The succinct "Summary" of JEP 345 states, "Improve G1 performance on large machines by implementing NUMA-aware memory allocation." Two important "non-goals" of this JEP indicate that the JEP is only intended to add NUMA (non-uniform memory access) support to the G1 garbage collector and only for Linux. However, the JEP also points out that "the parallel collector, enabled by by -XX:+UseParallelGC, has been NUMA-aware for many years."

JEP 361: Switch Expressions (Standard)

JEP 361 moves switch expressions from their JEP 325 "preview" status to "standard" status. Along the way, JEP 354 (targeted at JDK 13) made this change to the preview switch expressions feature: "To yield a value from a switch expression, the break with value statement is dropped in favor of a yield statement." The "History" section of JEP 361 discusses switch expressions support in preview status in JDK 12 and JDK 13 and explains why it is proposed for standard status with JDK 14: "Feedback on JDK 13 suggests that this feature is now ready to be made final and permanent in JDK 14."

JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector

JEP 363's concise "Summary" states, "Remove the Concurrent Mark Sweep (CMS) garbage collector." The Concurrent Mark Sweep (CMS) garbage collector was deprecated with JEP 291 (JDK 9) and this JEP aims to remove it altogether with JDK 14.

JEP 364: ZGC on macOS / JEP 365: ZGC on Windows

The goals of JEP 364 and JEP 365 are to "port the ZGC garbage collector" to macOS and Windows operating systems respectively.

JEP 364's "Motivation" section states, "While we expect users that require the scalability of ZGC to use Linux-based environments, it is not uncommon that developers use Macs for local development and testing, before deploying applications." Although JEP 365 lacks an explicit "Motivation" section, its motivation is probably similar to that for JEP 364.

JEP 365's "Non-Goals" section states, "It is not a goal to support Windows 10 and Windows Server older than version 1803, since older versions lack the required API for placeholder memory reservations."

JEP 367: Remove the Pack200 Tools and API

The "Summary" section of JEP 367 begins with this statement, "Remove the pack200 and unpack200 tools, and the Pack200 API in the java.util.jar package." This removal of these tools and APIs was advertised in Java SE 11 via JEP 336 when they were deprecated.

The "Motivation" sections of both the deprecation JEP 336 and the removal JEP 367 list three reasons for deprecating and removing Pack200 and conclude with this statement, "Overall, the cost of maintaining Pack200 is significant, and outweighs the benefit of including it in Java SE and the JDK."

The "Risks and Assumptions" section of JEP 336 includes this statement, "We assume that developers who use pack200 to shrink application JARs can switch to either the jlink tool or the jpackage tool to create application-specific runtimes with an optimized form factor." There is discussion regarding the suitability of jlink and jpackage on the r/java sub-reddit.

Java SE Specification Impacts

Iris Clark has posted that two of these JEPs have Java SE scope. She writes that JEP 361 (switch expressions standard) and JEP 367 (removing Pack200) are "of scope 'SE' [and] have been Proposed to Target for Java SE 14."

Conclusion

If all six of these JEPs proposed for JDK 14 get targeted for JDK 14, there will be nine JEPs associated with JDK 14. Two that I'm particularly looking forward to are the standardizing the switch expressions feature with JEP 361 and better NPE messages with JEP 358.

Saturday, October 26, 2019

Better NPE Messages in JDK 14

My March 2019 blog post "Better Default NullPointerException Messages Coming to Java?" was written when the draft JEP for better NullPointerException messages had not yet been targeted to a particular JDK release. Since then, that draft JEP became JEP 358 ("Helpful NullPointerExceptions"), which has been targeted for JDK 14. Even better, the initial implementation (JDK-8218628) is already in the JDK 14 branch and is available to play with in JDK 14 Early Access Builds Build 20 (2019/10/23).

In this post, I will run the example code introduced in my previous post against the JDK 14 Early Access Build 20 to demonstrate the additional details now provided. To see that example code that was written to intentionally introduce a variety of situations resulting in NullPointerExceptions, see that earlier post or view the source code on GitHub.

With the JDK 14 Early Access Build 20 downloaded and pointed to by my path, I see the following when I run java -version:

openjdk version "14-ea" 2020-03-17
OpenJDK Runtime Environment (build 14-ea+20-879)
OpenJDK 64-Bit Server VM (build 14-ea+20-879, mixed mode, sharing)

With the JDK 14 Early Access Build 20 configured appropriately, I rebuilt the source code mentioned previously and then re-ran the code with the java launcher without any new options. The output from this (shown below) is not materially different from the output with previous JDK versions.

=========================================
| #1: Element [0] on null boolean array |
=========================================

java.lang.NullPointerException
 at dustin.examples.npe.NpeDemo.demonstrateFirstExampleIndexAccessOnNullBooleanArray(Unknown Source)
 at dustin.examples.npe.NpeDemo.demonstrateJdk8218628Examples(Unknown Source)
 at dustin.examples.npe.NpeDemo.main(Unknown Source)

=================================
| #2: .length on null boolean[] |
=================================

java.lang.NullPointerException
 at dustin.examples.npe.NpeDemo.demonstrateSecondExampleLengthOnNullBooleanArray(Unknown Source)
 at dustin.examples.npe.NpeDemo.demonstrateJdk8218628Examples(Unknown Source)
 at dustin.examples.npe.NpeDemo.main(Unknown Source)

=======================================
| #3: Assigning float to null float[] |
=======================================

java.lang.NullPointerException
 at dustin.examples.npe.NpeDemo.demonstrateThirdExampleAssigningValueToElementOfNullFloatArray(Unknown Source)
 at dustin.examples.npe.NpeDemo.demonstrateJdk8218628Examples(Unknown Source)
 at dustin.examples.npe.NpeDemo.main(Unknown Source)

======================================
| #4: Accessing field on null object |
======================================

java.lang.NullPointerException
 at dustin.examples.npe.NpeDemo.demonstrateFourthExampleAccessInstanceFieldOfNullObject(Unknown Source)
 at dustin.examples.npe.NpeDemo.demonstrateJdk8218628Examples(Unknown Source)
 at dustin.examples.npe.NpeDemo.main(Unknown Source)

===================
| #5: throw null; |
===================

java.lang.NullPointerException
 at dustin.examples.npe.NpeDemo.demonstrateFifthExampleThrowingConstantNull(Unknown Source)
 at dustin.examples.npe.NpeDemo.demonstrateJdk8218628Examples(Unknown Source)
 at dustin.examples.npe.NpeDemo.main(Unknown Source)

================================================
| #6: Method invocation on null instance field |
================================================

java.lang.NullPointerException
 at dustin.examples.npe.NpeDemo.demonstrateSixthExampleMethodInvocationOnNullInstanceField(Unknown Source)
 at dustin.examples.npe.NpeDemo.demonstrateJdk8218628Examples(Unknown Source)
 at dustin.examples.npe.NpeDemo.main(Unknown Source)

=============================================
| #7: synchronized() on null instance field |
=============================================

java.lang.NullPointerException
 at dustin.examples.npe.NpeDemo.demonstrateSeventhExampleSynchronizedNullInstanceField(Unknown Source)
 at dustin.examples.npe.NpeDemo.demonstrateJdk8218628Examples(Unknown Source)
 at dustin.examples.npe.NpeDemo.main(Unknown Source)

==========================================================================
| >>> Null Lost in Long Series of Method Invocations in Single Statement |
==========================================================================

java.lang.NullPointerException
 at dustin.examples.npe.NpeDemo.demonstrateNullLostInSeriesOfMethodInvocationsInSingleStatement(Unknown Source)
 at dustin.examples.npe.NpeDemo.main(Unknown Source)

=======================================================
| >>> Null Lost in Dereferenced Constructor Arguments |
=======================================================

java.lang.NullPointerException
 at dustin.examples.npe.NpeDemo.demonstrateNullLostInConstructorAcceptingMultiplePotentiallyNullArgumentsDereferenced(Unknown Source)
 at dustin.examples.npe.NpeDemo.main(Unknown Source)

==================================================
| >>> Null Lost in Dereferenced Method Arguments |
==================================================

java.lang.NullPointerException
 at dustin.examples.npe.NpeDemo.demonstrateNullLostInMethodAcceptingMultiplePotentiallyNullArgumentsDereferenced(Unknown Source)
 at dustin.examples.npe.NpeDemo.main(Unknown Source)

As the above output demonstrates, even with the new JDK 14 Early Access Build 20, I don't see any new detailed information regarding NullPointerExceptions when I run my application as normal. I included this output to show that a special flag is needed to enable the more detailed NullPointerExceptions and to make it more convenient to compare the output without and with the extra details. The next output listing shows the additional details provided when the java launcher is passed the flag -XX:+ShowCodeDetailsInExceptionMessages:

=========================================
| #1: Element [0] on null boolean array |
=========================================

java.lang.NullPointerException: Cannot load from byte/boolean array because "<local1>" is null
 at dustin.examples.npe.NpeDemo.demonstrateFirstExampleIndexAccessOnNullBooleanArray(Unknown Source)
 at dustin.examples.npe.NpeDemo.demonstrateJdk8218628Examples(Unknown Source)
 at dustin.examples.npe.NpeDemo.main(Unknown Source)

=================================
| #2: .length on null boolean[] |
=================================

java.lang.NullPointerException: Cannot read the array length because "<local1>" is null
 at dustin.examples.npe.NpeDemo.demonstrateSecondExampleLengthOnNullBooleanArray(Unknown Source)
 at dustin.examples.npe.NpeDemo.demonstrateJdk8218628Examples(Unknown Source)
 at dustin.examples.npe.NpeDemo.main(Unknown Source)

=======================================
| #3: Assigning float to null float[] |
=======================================

java.lang.NullPointerException: Cannot store to float array because "<local1>" is null
 at dustin.examples.npe.NpeDemo.demonstrateThirdExampleAssigningValueToElementOfNullFloatArray(Unknown Source)
 at dustin.examples.npe.NpeDemo.demonstrateJdk8218628Examples(Unknown Source)
 at dustin.examples.npe.NpeDemo.main(Unknown Source)

======================================
| #4: Accessing field on null object |
======================================

java.lang.NullPointerException: Cannot read field "nullInstanceField" because "<local1>" is null
 at dustin.examples.npe.NpeDemo.demonstrateFourthExampleAccessInstanceFieldOfNullObject(Unknown Source)
 at dustin.examples.npe.NpeDemo.demonstrateJdk8218628Examples(Unknown Source)
 at dustin.examples.npe.NpeDemo.main(Unknown Source)

===================
| #5: throw null; |
===================

java.lang.NullPointerException: Cannot throw exception because "null" is null
 at dustin.examples.npe.NpeDemo.demonstrateFifthExampleThrowingConstantNull(Unknown Source)
 at dustin.examples.npe.NpeDemo.demonstrateJdk8218628Examples(Unknown Source)
 at dustin.examples.npe.NpeDemo.main(Unknown Source)

================================================
| #6: Method invocation on null instance field |
================================================

java.lang.NullPointerException: Cannot invoke "String.isEmpty()" because "this.nullInstanceField" is null
 at dustin.examples.npe.NpeDemo.demonstrateSixthExampleMethodInvocationOnNullInstanceField(Unknown Source)
 at dustin.examples.npe.NpeDemo.demonstrateJdk8218628Examples(Unknown Source)
 at dustin.examples.npe.NpeDemo.main(Unknown Source)

=============================================
| #7: synchronized() on null instance field |
=============================================

java.lang.NullPointerException: Cannot enter synchronized block because "this.nullInstanceField" is null
 at dustin.examples.npe.NpeDemo.demonstrateSeventhExampleSynchronizedNullInstanceField(Unknown Source)
 at dustin.examples.npe.NpeDemo.demonstrateJdk8218628Examples(Unknown Source)
 at dustin.examples.npe.NpeDemo.main(Unknown Source)

==========================================================================
| >>> Null Lost in Long Series of Method Invocations in Single Statement |
==========================================================================

java.lang.NullPointerException: Cannot invoke "dustin.examples.npe.DysfunctionalLocation$Province.getCity()" because the return value of "dustin.examples.npe.DysfunctionalLocation$Nation.getProvince()" is null
 at dustin.examples.npe.NpeDemo.demonstrateNullLostInSeriesOfMethodInvocationsInSingleStatement(Unknown Source)
 at dustin.examples.npe.NpeDemo.main(Unknown Source)

=======================================================
| >>> Null Lost in Dereferenced Constructor Arguments |
=======================================================

java.lang.NullPointerException: Cannot invoke "java.lang.Long.longValue()" because "<local6>" is null
 at dustin.examples.npe.NpeDemo.demonstrateNullLostInConstructorAcceptingMultiplePotentiallyNullArgumentsDereferenced(Unknown Source)
 at dustin.examples.npe.NpeDemo.main(Unknown Source)

==================================================
| >>> Null Lost in Dereferenced Method Arguments |
==================================================

java.lang.NullPointerException: Cannot invoke "java.lang.Long.longValue()" because "<local6>" is null
 at dustin.examples.npe.NpeDemo.demonstrateNullLostInMethodAcceptingMultiplePotentiallyNullArgumentsDereferenced(Unknown Source)
 at dustin.examples.npe.NpeDemo.main(Unknown Source)

JEP 358 explains the use of this flag for seeing additional NullPointerException details: "The feature can be toggled with the new boolean command-line option -XX:{+|-}ShowCodeDetailsInExceptionMessages. The option will first have default 'false' so that the message is not printed. It is intended to enable code details in exception messages by default in a later release." As we see, this feature is initially turned off by default, but there is a plan to enable the more detailed NullPointerException messages in the future.

A recent Tweet asked the question, "How it will work if bytecode doesn’t contain variable names?" The question continued by providing a specific example: "Suppose we have code like Object a = ....; a.getName(); //NPE What kinds of message NPE would have?" Although an example of this is included in my battery of tests shown earlier, I thought I'd provide a more focused example here in response to that question. The next code listing (which is also available on GitHub) shows code adapted from the example used in the Tweet.

package dustin.examples.npe;

/**
 * Simple demonstration to answer Tweet-ed question
 * "How it will work if bytecode doesn't contain variable names?"
 * (https://twitter.com/2doublewhiskey/status/1180365953240055809).
 */
public class TwoDoubleWhiskeyTweetExample
{
   public static void main(final String[] arguments)
   {
      final Person person = null;
      person.getName(); //NPE
   }
   
   public static class Person
   {
      private String name;

      public Person(final String newName)
      {
         name = newName;
      }

      public String getName()
      {
         return name;
      }
   }
}

The next screen snapshot shows the result of running this simple application with the JDK 14 Early Access Build 20 without and then with the java launcher flag -XX:+ShowCodeDetailsInExceptionMessages.

As the screen snapshot indicates, using the -XX:+ShowCodeDetailsInExceptionMessages flag with the JDK 14 Early Access Build 20 provides this additional detail related to this simple NullPointerException example: "Cannot invoke "dustin.examples.npe.TwoDoubleWhiskeyTweetExample$Person.getName()" because "<local1>" is null"

An example that is simpler and even closer to the original example provided in the Tweet-ed question is available on GitHub.

JEP 358 ("Helpful NullPointerExceptions") may not be as flashy as some other JEPs that come to new JDK releases, but it may be one that in the end provides more value to Java developers on a daily basis than some of its flashier peers. There are numerous examples where this will be helpful and many of those example situations are spelled out in the JEP itself and in my code examples referenced in this post.

Monday, September 2, 2019

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.

Thursday, August 29, 2019

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.

Friday, August 16, 2019

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

Thursday, August 15, 2019

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).

Saturday, August 3, 2019

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.

Monday, July 29, 2019

JEP 358: Helpful NullPointerExceptions

In the post "Better Default NullPointerException Messages Coming to Java?", I summarized background details related to a draft JEP (at that time) regarding making some types of NullPointerException's (NPE's) messages more useful. It was nice to see last week that this JEP is now a candidate JEP (JEP 358: "Helpful NullPointerExceptions"). In this post, I highlight aspects of JEP 358 that I find particularly interesting.

What is JEP 358?

JEP 358's current "Summary" succinctly describes this JEP: "Improve the usability of NullPointerExceptions generated by the JVM by describing precisely which variable was null."

The "Motivations" section of JEP 358 includes this paragraph: "The entire Java ecosystem would benefit if the JVM could give the information needed to pinpoint the source of an NPE and then identify its root cause, without using extra tooling or shuffling code around. SAP's commercial JVM has done this since 2006, to great acclaim from developers and support engineers."

Example of Community Contribution to OpenJDK

One aspect of JEP 358 that interests me is its background. The "Testing" section of JEP 358 currently states that "a predecessor implementation has been in SAP's commercial JVM since 2006 and has proven to be stable." The intention of this statement is to demonstrate that some testing has already taken place for the feature, but it also points out that SAP and its personnel are the major contributors of this proposed JDK enhancement. The authors of the JEP, Goetz Lindenmaier and Ralf Schmelter (credited as original author), are or have been affiliated with SAP. My understanding is that the SAP OpenJDK release (SapMachine) does not include this feature yet, but the commercial SAP does. This proposed JDK enhancement is a nice example of how having multiple vendors delivering implementations of OpenJDK might benefit OpenJDK for everyone in the future.

The Downside of More Details

JEP 358 addresses a potential security risk introduced by more detailed NPEs. It states that "the null-detail message may contain variable names from the source code ... if debug information is included in the class file (javac -g)" and "these have not previously been available to other programs via Java's reflection APIs."

Enabling Detailed Null Messages

The "Alternatives" section of JEP 358 outlines three reasons that one might not want the newer more detailed NPE messages (performance, security, and compatibility). It states, "The null-detail message is switched off per default and can be enabled by command-line option -XX:+SuppressCodeDetailsInExceptionMessages." That section adds that "there is no way to specify that only some NPE-raising bytecodes are of interest" (in other words, it's an all-or-nothing option). The section concludes with this statement, "We intend to enable the null-detail message by default in a future release."

More Detailed Messages Are Not for All NullPointerExceptions

JEP 358 points out types of NullPointerExceptions to which the more detailed messages will apply and contrasts that with the types to which the more detailed messages will not apply. It states (I added emphasis), "Only NPEs that are created and thrown directly by the JVM will include the null-detail message. NPEs that are explicitly created and/or explicitly thrown by programs running on the JVM are not subject to the bytecode analysis and null-detail message creation described below. In addition, the null-detail message is not reported for NPEs caused by code in hidden methods, which are special-purpose low-level methods generated and called by the JVM to, e.g., optimize string concatenation. A hidden method has no filename or line number that could help to pinpoint the source of an NPE, so printing a null-detail message would be futile." As the text states, there is no reason to attempt to provide details for "hidden methods." As for NPEs our own code explicitly throws, we have the ability to add useful context to those exceptions' messages already when we construct them.

Conclusion

The responses to this JEP have been enthusiastic and I think there are many Java developers who look forward to the availability of more detailed NullPointerException messages in future OpenJDK distributions. JDK-8218628 ("Add detailed message to NullPointerException describing what is null.") is associated with JEP 358 (JDK-8220715) and is currently associated with JDK 14 as the "Fix Version." Here's hoping for JEP 358 to be officially targeted to JDK 14!

Tuesday, July 9, 2019

Signs of JDK 14 Beginning to Appear

JDK 13 is currently in Rampdown Phase 1 (RDP 1), is scheduled to enter Rampdown Phase 2 (RDP 2) in a little over one week (on 18 July 2019), and is tentatively scheduled for General Availability on 17 September 2019. What this means, of course, is that it's time to start thinking about JDK 14! This post references and summarizes some of the online resources related to JDK 14 that are starting to appear.

Project JDK 14

The main OpenJDK JDK 14 page is the best place to start when wishing to see an overview of the release and its progress. Besides a reference to its associated specification (JSR 389: "Java SE 14 Platform"), the only other information available on this page as of this writing is a simple "Status" paragraph that references development repositories and the JDK Enhancement Proposal (JEP) process.

JDK 14 Early Access Builds

JDK 14 Early Access Builds are already available! As of this writing, the latest is Build 4 (2019/7/3). Not surprisingly, the commits in the JDK 14 early access builds at this time are fixes made to earlier JDK versions that will also be available in JDK 14.

Proposed JEP 352

The Mark Reinhold e-mail message "JEP proposed to target JDK 14: 352: Non-Volatile Mapped Byte Buffers" proposes that JEP 352 ("Non-Volatile Mapped Byte Buffers") be targeted to JDK 14.

JDK 14 Speculations

It's really far too early to recklessly speculate on what might land in JDK 14, but I won't let that stop me. It seems that the two JDK 13 "preview" JEPs [JEP 354 ("Switch Expressions") and JEP 355 ("Text Blocks")] could potentially become "permanent" in JDK 14. JEP 343 ("Packaging Tool") is another that could potentially be targeted for JDK 14.

Saturday, July 6, 2019

Project Valhalla: A First Look at LW2 Inline Types

I summarized some recent Project Valhalla LW2 "inline types" progress that was made public recently in my blog post "Valhalla LW2 Progress - Inline Types." In this post, I illustrate some of the concepts summarized in that post with code examples executed against recently released Valhalla Early Access Build jdk-14-valhalla+1-8 (2019/7/4). All code examples featured in this post are available on GitHub.

The OpenJDK Wiki page "LW2" provides an illustrative example of inline types via source code for a class called "InlineType." My example makes some minor adaptions and additions to this class and is available on GitHub as a class called InlineTypeExample. Some items that stand out immediately when reviewing this source code are the presence of the keyword inline and the presence of the ? in the Comparable's generic parameter.

The source code for my adapted InlineTypeExample class has an attempt to have the inline type class extend another class commented out because that leads to a compiler error: error: Inline type may not extend another inline type or class

Similarly, that source code also has the method that attempts to set the integer field of the inline type class commented out because that will also not compile: error: cannot assign a value to final variable

With the current Valhalla LW2 build, I'm allowed to make my inline type class Serializable and it still compiles successfully.

Another GitHub-hosted illustrative class is Lw2Demonstration that compares and contrasts characteristics of the inline type class (and instances of it) to the JDK-provided java.lang.Integer class (and its instances) and to a simple custom-built Integer wrapper (and its instances). This demonstration class calls reflective methods (some which are new to the JDK 14-based Valhalla build) on the "class" types of all three things (inline type, Integer, and custom Integer wrapper) and calls some "common" methods [toString(), equals(Object), hashCode()] on instances of all three types.

Two methods are commented out in the class Lw2Demonstration because they each attempt to perform functionality on the inline type that is not supported for inline types. One of these methods attempts to synchronize on a variable of the inline type. When attempting to compile this synchronization of an inline type, the following compiler error message is seen: error: unexpected type ... required: reference ... found: InlineTypeExample

Another attempts to assign an inline type to null. When attempting to compile this, the following error message is encountered: error: incompatible types: <null> cannot be converted to InlineTypeExample

The following method from Lw2Demonstration writes out several metadata characteristics of the class types.

/**
 * Provides metadata extracted from the provided instance of
 * {@link Class} as a single {@link String}.
 *
 * @param classToInvokeInlineMethodsOn Class for which metadata
 *    is to be extracted and returned in {@link String} format;
 *    should NOT be {@code null}.
 * @return Single string representation of metadata extracted
 *    from the provided {@link Class} instance.
 * @throws NullPointerException Thrown if {@code null} is
 *    provided for my sole parameter.
 */
public static String extractClassMetadata(final Class classToInvokeInlineMethodsOn)
{
   Objects.requireNonNull("Provided Class must be non-null to extract its metadata.");

   final String className = classToInvokeInlineMethodsOn.getSimpleName();
   final String outputPrefix = "\n" + className + ".class.";
   return outputPrefix + "getName(): " + classToInvokeInlineMethodsOn.getName()
      + outputPrefix + "getSimpleName(): " + classToInvokeInlineMethodsOn.getSimpleName()
      + outputPrefix + "getCanonicalName(): " + classToInvokeInlineMethodsOn.getCanonicalName()
      + outputPrefix + "toGenericString(): " + classToInvokeInlineMethodsOn.toGenericString()
      + outputPrefix + "getTypeName(): " + classToInvokeInlineMethodsOn.getTypeName()
      + outputPrefix + "getComponentType(): " + classToInvokeInlineMethodsOn.getComponentType()
      + outputPrefix + "isInlineClass(): " + classToInvokeInlineMethodsOn.isInlineClass()
      + outputPrefix + "isIndirectType(): " + classToInvokeInlineMethodsOn.isIndirectType()
      + outputPrefix + "isNullableType(): " + classToInvokeInlineMethodsOn.isNullableType()
      + outputPrefix + "isPrimitive(): " + classToInvokeInlineMethodsOn.isPrimitive()
      + outputPrefix + " final?: " + isFinal(classToInvokeInlineMethodsOn);
}

Some of the methods invoked on the Class instance in the previous method are new to the JDK 14-based Valhalla LW2 early access build. These include isInlineClass(), isIndirectType(), and isNullableType().

The main demonstration class Lw2Demonstration creates instances of the inline type class InlineTypeExample, of JDK-provided java.lang.Integer, and of a custom wrapper for an Integer. The demonstration then runs instances of these three classes and the class definitions through the same methods and writes out the results for each so that they can be compared and contrasted. Here is the output from running this example against the Valhalla Early Access Build mentioned at the beginning of this post.

InlineTypeExample.class.getName(): dustin.examples.valhalla.lw2.InlineTypeExample
InlineTypeExample.class.getSimpleName(): InlineTypeExample
InlineTypeExample.class.getCanonicalName(): dustin.examples.valhalla.lw2.InlineTypeExample
InlineTypeExample.class.toGenericString(): public final inline class dustin.examples.valhalla.lw2.InlineTypeExample
InlineTypeExample.class.getTypeName(): dustin.examples.valhalla.lw2.InlineTypeExample
InlineTypeExample.class.getComponentType(): null
InlineTypeExample.class.isInlineClass(): true
InlineTypeExample.class.isIndirectType(): false
InlineTypeExample.class.isNullableType(): false
InlineTypeExample.class.isPrimitive(): false
InlineTypeExample.class. final?: true
InlineTypeExample: toString(): [dustin.examples.valhalla.lw2.InlineTypeExample someIntegerValue=1]
InlineTypeExample: hashCode(): 1303372796
Inline Type Example ==: true

Integer.class.getName(): java.lang.Integer
Integer.class.getSimpleName(): Integer
Integer.class.getCanonicalName(): java.lang.Integer
Integer.class.toGenericString(): public final class java.lang.Integer
Integer.class.getTypeName(): java.lang.Integer
Integer.class.getComponentType(): null
Integer.class.isInlineClass(): false
Integer.class.isIndirectType(): true
Integer.class.isNullableType(): true
Integer.class.isPrimitive(): false
Integer.class. final?: true
Integer: toString(): 1
Integer: hashCode(): 1
Integer Type Example ==: false

IntegerWrapper.class.getName(): dustin.examples.valhalla.lw2.IntegerWrapper
IntegerWrapper.class.getSimpleName(): IntegerWrapper
IntegerWrapper.class.getCanonicalName(): dustin.examples.valhalla.lw2.IntegerWrapper
IntegerWrapper.class.toGenericString(): public class dustin.examples.valhalla.lw2.IntegerWrapper
IntegerWrapper.class.getTypeName(): dustin.examples.valhalla.lw2.IntegerWrapper
IntegerWrapper.class.getComponentType(): null
IntegerWrapper.class.isInlineClass(): false
IntegerWrapper.class.isIndirectType(): true
IntegerWrapper.class.isNullableType(): true
IntegerWrapper.class.isPrimitive(): false
IntegerWrapper.class. final?: false
IntegerWrapper: toString(): dustin.examples.valhalla.lw2.IntegerWrapper@5442a311
IntegerWrapper: hashCode(): 1413653265
Integer Wrapper Example ==: false

The output shown above demonstrates some of the advertised characteristics of the inline type. The most interesting are the focus of the following table.

CharacteristicInline Type Wrapping Integerjava.lang.IntegerCustom Integer Wrapper
Inline?truefalsefalse
Indirect?falsetruetrue
Nullable?falsetruetrue
Final?truetruefalse
== Valid for Equality?truefalsefalse
toString()Implicitly CustomizedExplicitly CustomizedUses Object's
hashCode()Implicitly CustomizedExplicitly CustomizedUses Object's

To compile and execute these examples, I needed to provide the Java compiler and launcher with some special arguments. Specifically, I compiled with --enable-preview, -Xlint:preview, and -source 14. For executing the demonstration, I passed the flag --enable-preview to the Java launcher.

The updated Valhalla Early Access Build [Build jdk-14-valhalla+1-8 (2019/7/4)] provides a convenient pre-built binary for Java developers interested in trying out Valhalla LW2 prototype inline types. This post has demonstrated some of these current LW2 inline types concepts using this build. Rémi Forax has provided many more examples on GitHub (forax/valuetype-lworld).