The show must go on: JDK-18 is here!

It feels like JDK-17 release just landed not so long ago, but there is a new one already out: please welcome JDK-18! Although it is not an LTS release, there are quite a few interesting features to talk about (the preview and incubator ones are not included).

• JEP-400: UTF-8 by Default: specifies UTF-8 as the default charset of the standard Java APIs. With this change, APIs that depend upon the default charset will behave consistently across all implementations, operating systems, locales, and configurations. In JDK-17 and earlier, the default charset is determined when the Java runtime starts and this behavior could be restored in JDK-18 using file.encoding system property by setting it to "COMPAT": -Dfile.encoding=COMPAT (the other supported value of this property is "UTF-8").

• JEP-416: Reimplement Core Reflection with Method Handles: reimplements java.lang.reflect.Method, Constructor, and Field on top of java.lang.invoke method handles. Making method handles the underlying mechanism for reflection will reduce the maintenance and development cost of both the java.lang.reflect and java.lang.invoke APIs. To mitigate the compatibility risks, there is possibility to enable the old implementation via -Djdk.reflect.useDirectMethodHandle=false system property.

• JEP-418: Internet-Address Resolution SPI: defines a service-provider interface (SPI) for host name and address resolution, so that java.net.InetAddress can make use of resolvers other than the platform's built-in resolver. The new classes java.net.spi.InetAddressResolver and java.net.spi.InetAddressResolverProvider have been added into the standard library.

• JEP-421: Deprecate Finalization for Removal: deprecates finalization for removal in a future release. Finalization remains enabled by default for now, but can be disabled (via the new command-line option --finalization=disabled) to facilitate early testing. In a future release it will be disabled by default, and in a later release it will be removed. Maintainers of libraries and applications that rely upon finalization should consider migrating to other resource management techniques such as the try-with-resources statement and cleaners.

• JEP-408: Simple Web Server: provides a command-line tool to start a minimal web server that serves static files only. No CGI or servlet-like functionality is available. This tool will be useful for prototyping, ad-hoc coding, and testing purposes, particularly in educational contexts. The following (new!) command line tool starts the Simple Web Server:

    $ jwebserver
      

  Alternatively, the components of the Simple Web Server (i.e., server, handler, and filter) could be accessed through the API and integrated into existing applications, if needed. The following new packages contain Simple Web Server SPI and implementation:

  • com.sun.net.httpserver
  • com.sun.net.httpserver.spi

  The quick example of the Simple Web Server API in action is below:

          var handler = new HttpHandler() {
              public void handle(HttpExchange exchange) throws IOException {
                  final String response = "OK";
                  exchange.sendResponseHeaders(200, response.length());
                  try (OutputStream os = exchange.getResponseBody()) {
                      os.write(response.getBytes());
                  }
              }
          };
  
          final HttpServer server = HttpServer.create(new InetSocketAddress(9091), 0);
          server.createContext("/", handler);
          server.start();
      

• JEP-413: Code Snippets in Java API Documentation: introduces an @snippet tag for JavaDoc's Standard Doclet, to simplify the inclusion of example source code in API documentation. This is probably one of the most interesting features of the JDK-18, let us take a look at it more closely by illustrating the usage of the Simple Web Server APIs usage.

      /**
       * The following code snippet shows how to use {@code HttpServer}:
       * {@snippet :
       *  final HttpServer server = HttpServer.create(new InetSocketAddress(9091), 0);
       *  server.createContext("/", handler);
       *  server.start();
       *  }
       */
    

  In this case, the snippet is embedded however it could also be externalized, for example:

      /**
       * The following code snippet shows how to use {@code HttpServer}:
       * {@snippet file="SimpleWebServerStarter.java" region="server"}
       */
      

  And here is the relevant part of the SimpleWebServerStarter.java content:

          var handler = ...;
  
          // @start region="server"
          final HttpServer server = HttpServer.create(new InetSocketAddress(9091), 0);
          server.createContext("/", handler);
          server.start();
          // @end
      

  In my opinion, the code snippets should significantly improve the quality and usefulness of Java documentation, hopefully we are going to see them getting traction. If you want to dig deeper, Dustin Marx has published an excellent post on the subject with more details.

• JDK-8253119: Remove the legacy PlainSocketImpl and PlainDatagramSocketImpl implementation. With that, the respective replacement delivered by JEP-353 and JEP-373 becomes the only implementation available going forward.

• JDK-8256425: Obsolete Biased Locking: finally wraps up JEP-374 which was supposed to be delivered in JDK-15 but was postponed due to community feedback.

• Support for string deduplication, used to be available in G1 only, was finally rolled into other garbage collectors: SerialGC, ParallelGC and ZGC.

• JDK-8275056: Virtualize G1CardSet containers over heap region: allows arbitrary combinations of the card table size with any heap region size.

• C2 compiler was enhanced with JDK-8259609: C2: optimize long range checks in long counted loops, JDK-8276116: C2: optimize long range checks in int counted loops and JDK-8276162: C2: Optimise unsigned comparison pattern.

• Notably, C1 compiler got JDK-8274983: C1: optimizes the invocation of private interface methods and JDK-8265518: C1: Intrinsic support for Preconditions.checkIndex

• JDK-8273278: Support XSLT on GraalVM Native Image--deterministic bytecode generation in XSLT: fixes quite annoying issue when native-image can not match the hash of the runtime-generated bytecode to the pre-defined classes.

• JDK-8189591: No way to locally suppress doclint warnings: it becomes now possible to use @SuppressWarnings annotation to suppress messages from DocLint about issues in documentation comments, when it is not possible or practical to fix the issues that were found.

• JDK-8266936: Add a finalization JFR event: introduces a new JDK Flight Recorder event, jdk.FinalizerStatistics, to help identify classes that still use finalizers (at runtime).

• JDK-8274335: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields: expand javac's -Xlint:serial from checking the declaration of serialVersionUID fields to checking the declarations of all serialization-related fields and methods.

• JDK-8277861: Terminally deprecate Thread.stop: terminally deprecates Thread.stop method so it can be degraded and removed in the future release.

• JDK-8133686: HttpURLConnection's getHeaderFields method returns field values in reverse order: the multiple header values for a given field-name are now returned in the order in which they were added.

• JDK-8251329: Files.walkFileTree walks infinitely if zip has dir named "." inside: the ZIP file system provider has been changed to reject existing ZIP files that contain entries with "." or "..".

• JDK-8231640: Canonical property storage: introduces a new system property, java.properties.date, to allow applications to control the default date comment written out by the java.util.Properties::store methods.

• The java.nio.charset.Charset class got a new method:

  • static Charset forName(String charsetName, Charset fallback)

• The java.time.Duration got some love as well:

  • boolean isPositive()

• A new method went into java.io.PrintStream class:

  • Charset charset()

• The java.io.FileInputStream got a specialized implementation of (JDK-8272297):

  • long transferTo(java.io.OutputStream) throws IOException (overridden)

• One new method found its way into javax.lang.model.element.ExecutableElement interface:

  • Element getEnclosingElement()

• And a few methods were added to javax.lang.model.util.Elements interface:

  • TypeElement getOutermostTypeElement(Element e)
  • JavaFileObject getFileObjectOf(Element e)

• A very useful additions to javax.lang.model.SourceVersion enumeration to support mappings to runtime version:

  • Runtime.Version runtimeVersion()
  • static SourceVersion valueOf(Runtime.Version rv)

• The annotation processing got some improvements in the scope of javax.annotation.processing.Messager interface:

  • void printError(CharSequence msg)
  • void printError(CharSequence msg, Element e)
  • void printWarning(CharSequence msg)
  • void printWarning(CharSequence msg, Element e)
  • void printNote(CharSequence msg)
  • void printNote(CharSequence msg, Element e)

• The largest set of changes went into java.lang.Math utility class:

  • static int ceilDiv(int x, int y)
  • static long ceilDiv(long x, int y)
  • static long ceilDiv(long x, long y)
  • static int ceilDivExact(int x, int y)
  • static long ceilDivExact(long x, long y)
  • static int ceilMod(int x, int y)
  • static int ceilMod(long x, int y)
  • static long ceilMod(long x, long y)
  • static int divideExact(int x, int y)
  • static long divideExact(long x, long y)
  • static int floorDivExact(int x, int y)
  • static long floorDivExact(long x, long y)
  • static long unsignedMultiplyHigh(long x, long y)

• And, similarly, to java.lang.StrictMath utility class:

  • static int ceilDiv(int x, int y)
  • static long ceilDiv(long x, int y)
  • static long ceilDiv(long x, long y)
  • static int ceilDivExact(int x, int y)
  • static long ceilDivExact(long x, long y)
  • static int ceilMod(int x, int y)
  • static int ceilMod(long x, int y)
  • static long ceilMod(long x, long y)
  • static int divideExact(int x, int y)
  • static long divideExact(long x, long y)
  • static int floorDivExact(int x, int y)
  • static long floorDivExact(long x, long y)
  • static long unsignedMultiplyHigh(long x, long y)

The JDK-18 comes in with a large number of the security enhancements, including further work on phasing out SecurityManager and its APIs:

• JDK-8231107: Allow store password to be null when saving a PKCS12 KeyStore

• JDK-8275252: Migrate cacerts from JKS to password-less PKCS12: by password-less, it means the certificates are not encrypted and it contains no MacData for integrity check.

• JDK-8255409: SunPKCS11 Provider Now Supports Some PKCS#11 v3.0 APIs

• JDK-8270380: Change the default value of the java.security.manager system property to disallow: quite an impactful change for the projects which still rely on SecurityManager.

• JDK-8269039: Disabled SHA-1 Signed JARs

• New methods added to Subject class as part of JDK-8267108: Alternate Subject.getSubject and doAs APIs that do not depend on Security Manager APIs:

  • static Subject current() (replacement for static Subject getSubject(AccessControlContext acc))
  • static <T> T callAs(Subject subject, Callable<T> action) throws CompletionException (replacement for static <T> T doAs(Subject subject, PrivilegedAction<T> action) and static <T> T doAs(Subject subject, PrivilegedExceptionAction<T> action) throws PrivilegedActionException)

• The KeyStore got one new method, in scope of JDK-8225181:

  • final Set<KeyStore.Entry.Attribute> getAttributes(String alias) throws KeyStoreException

• And KeyStoreSpi as well:

  • Set<KeyStore.Entry.Attribute> engineGetAttributes(String alias)

And while we are enjoying the perils of JDK-18, the early access builds of JDK-19 are already available. There are not much details of what is coming just yet, but may be Project Loom would finally make its appearance in some form or another? Who knows ...

Peace to everyone!