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):
- Enhancement JDK-8215038: Add a page that lists all system properties
- “new page that lists all system properties”
- This new page also shows what accesses each defined system property.
- Enhancement JDK-8235334: Deprecate jcmd GC.class_stats
- “The output of this jcmd GC.class_stats is lengthy and not well suited to understanding memory used by metaspace objects, nor is it a GC specific facility. It also has some open bugs.”
- Only looks deprecated in JDK 14, but may be removed altogether in JDK 15: “We should deprecate this in 14 and remove in 15.”
- “
-Xlog:cds
during-Xshare:dump
is an example of a better utility that uses a newer better mechanism in the source code.”
- Enhancement JDK-8222756: Plural support in CompactNumberFormat
- Changes to ContactNumberFormat‘s support for plurals for German and Italian
- Sub-Task JDK-8234542: Remove Pack200 Tools and API
- Associated with JEP 367 (“Remove the Pack200 Tools and API”) [JDK-8232022].
- Three main motivations listed for removing the Pack200 compression scheme for JAR files:
- Download issues historically associated with JDK have been overcome by events and the JDK itself has used compression alternatives instead of Pack200 since JDK 9.
- Applets in web browsers (a significant use case for Pack200 compression) are largely unsupported now.
- The “complex and elaborate technology” of Pack200 has a “file format is tightly coupled to the class file format and the JAR file format, both of which have evolved in ways unforeseen by JSR 200. … Overall, the cost of maintaining Pack200 is significant, and outweighs the benefit of including it in Java SE and the JDK.”
- Enhancement JDK-8234370: Implementation of JEP 362: Deprecate the Solaris and SPARC Ports
- Associated with JEP 362 (“Deprecate the Solaris and SPARC Ports”) [JDK-8231554]
- “Deprecate the Solaris/SPARC, Solaris/x64, and Linux/SPARC ports, with the intent to remove them in a future release.”
- Deprecation typically signals the beginning of the end and some will miss these ports when/if they are eventually removed.
- Sub-Task JDK-8233319: Deprecate MulticastSocket methods that operate on java.net.InetAddress
- Associated CSR JDK-8235330 (“Deprecate MulticastSocket methods that operate on java.net.InetAddress”) states that the following methods on class java.net.MulticastSocket are to be deprecated (but not yet removed and superior alternatives are shown for each):
- getInterface()
- Favor class’s getNetworkInterface() method
- setInterface(InetAddress inf)
- Favor class’s setNetworkInterface(NetworkInterface)
- joinGroup(InetAddress mcastaddr)
- Favor class’s joinGroup(SocketAddress, NetworkInterface)
- leaveGroup(InetAddress mcastaddr)
- Favor class’s leaveGroup(SocketAddress, NetworkInterface)
- getLoopbackMode()
- Favor DatagramSocket‘s (parent class’s) method getOption(SocketOption), passing StandardSocketOptions.html.IP_MULTICAST_LOOP to it
- setLoopbackMode(boolean disable)
- Favor DatagramSocket‘s (parent class’s) method setOption(SocketOption<T> name, T value), passing StandardSocketOptions.html.IP_MULTICAST_LOOP and
true
to it
- Favor DatagramSocket‘s (parent class’s) method setOption(SocketOption<T> name, T value), passing StandardSocketOptions.html.IP_MULTICAST_LOOP and
- getInterface()
- Associated CSR JDK-8235330 (“Deprecate MulticastSocket methods that operate on java.net.InetAddress”) states that the following methods on class java.net.MulticastSocket are to be deprecated (but not yet removed and superior alternatives are shown for each):
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.
Published on Java Code Geeks with permission by Dustin Marx, partner at our JCG program. See the original article here: JDK 14 Rampdown: Build 27 Opinions expressed by Java Code Geeks contributors are their own. |
Hi…
I’m Elena gillbertJDK 14 is now in Rampdown Phase One. Read this post to learn more. 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.