Posts

Showing posts from August, 2018

JDK Language Feature Preview in Action: Switch Expressions

JEP 12 ["Preview Language and VM Features"] is described on its main page as follows: A preview language or VM feature is a new feature of the Java SE Platform that is fully specified, fully implemented, and yet impermanent. It is available in a JDK feature release to provoke developer feedback based on real world use; this may lead to it becoming permanent in a future Java SE Platform. JEP 325 ["Switch Expressions (Preview)"] is, as the parenthetical in its title suggests, a " preview feature ." As such, JEP 325 provides a high-visibility early opportunity to use the JEP 12-outlined process to preview a new language feature. The recent messages on the OpenJDK jdk-dev mailing list provide evidence of the usefulness of JEP 325 in helping Java developers understand the implications of JEP 12 and the "preview feature" process. The discussion surrounding the "preview feature" nature of switch expressions (JEP 325) started with Mark ...

String.valueOf(Object) versus Objects.toString(Object)

The handy method String.valueOf(Object) has been around since JDK 1.0 and is one of the JDK-provided methods that I use on a frequent basis. I have blogged on its value before . The Objects class was introduced with JDK 1.7 and included the Objects.toString(Object) method. This post compares these two similar-sounding methods. Both methods String.valueOf(Object) and Objects.toString(Object) essentially do the same thing: call the toString() method on a passed-in object if it's not null or return the string "null" when null is passed to them. In short, both methods are designed to provide a simple approach for invoking an object's toString() without worry about a NullPointerException if it turned out to be null . The table below compares characteristics of the methods String.valueOf(Object) and Objects.toString(Object) . Characteristic String.valueOf(Object) Objects.toString(Object) Java SE 10 Method Javadoc " Returns the string represent...

Apache Commons ArrayUtils.toString(Object) versus JDK Arrays.toString(Object)

Apache Commons Lang provides an ArrayUtils class that includes the method toString(Object) that "Outputs an array as a String." In this post, I look at situations in which this method might still be useful when the JDK provides the Arrays.toString(Object[]) method [and several overloaded versions of that method on the Arrays class for arrays of primitive types]. At one point, a reason to use the Apache Commons Lang ArrayUtils.toString(Object) method might have been that there was no alternative provided by the JDK. Arrays.toString(Object[]) was introduced with J2SE 5 ( late 2004 ) where as Apache Commons Lang has had ArrayUtils.toString(Object) since at least Lang 2.0 ( late 2003 ). Although there's just over a year's difference between those releases, many organizations are more willing to upgrade libraries than JDK versions, so it's possible some organizations elected to use the Lang API because they had not yet adopted JDK even after its General Avai...

JDK 11: Release Candidate Update and OpenJDK JDK 11 LTS

JDK 11 is scheduled to be released for General Availability on Tuesday, 25 September 2018. A 16 August 2018 Mark Reinhold message on the OpenJDK jdk-dev mailing list announced that " JDK 11 is now in the Release Candidate Phase ." However, Reinhold provided updated details in a 17 August 2018 message on that same mailing list in which he stated, "We tagged the first Release Candidate build this morning ( jdk-11+27 ), but since there are some open P1 bugs ( http://j.mp/jdk-rc ) it's not actually a Release Candidate." Reinhold's last message concluded, "Stay tuned ..." The early access builds are available under " JDK 11 Early-Access Builds ," but the most current version available there as of this writing (18 August 2018) is Build 26 (2018/8/9) . The "JDK 11 Release Candidate Bugs" link provided by Reinhold currently shows two P1 bugs written against JDK 11: JDK-8207317 ["SSLEngine negotiation fail Exception beh...

Carefully Specify Multiple Resources in Single try-with-resources Statement

One of the more useful new features of Java 7 was the introduction of the try-with-resources statement [AKA Automatic Resource Management ( ARM )]. The attractiveness of the try-with-resources statement lies in its promise to "ensure that each resource is closed at the end of the statement." A "resource" in this context is any class that implements AutoCloseable and its close() method and is instantiated inside the "try" clause of the try-with-resources statement . The Java Language Specification [JLS] describes the try-with-resource statement in detail in Section 14.20.3 (of Java SE 10 JLS in this case). The JLS states that the " try -with-resources statement is parameterized with local variables (known as resources ) that are initialized before execution of the try block and closed automatically, in the reverse order from which they were initialized, after execution of the try block." The JLS clearly specifies that multiple resou...

APIs To Be Removed from Java 11

After seeing several APIs removed as part of Java 10 , Java 11 ( JSR 384 ) looks to remove some more APIs. In the recent OpenJDK java-se-spec-experts mailing list post " JSR 384 (Java SE 11) PFD Specification posted to jcp.org ," Iris Clark announced the availability of the Java SE 11 (18.9) Proposed Final Draft Specification . This document lists APIs that are being removed as part of Java 11. "Individual" (class/method) APIs are being removed in addition to the removal of entire modules. Individual APIs Being Removed in JDK 11 Class/Method Being Removed Additional Notes / References java.lang.Runtime.runFinalizersOnExit(boolean) Dangerous runFinalizersOnExit Deprecating Java's Finalizer java.lang.SecurityManager.checkAwtEventQueueAccess() Security Managers and Java SE JDK JDK-8177554 JDK-8029886 JDK-8186535 java.lang.SecurityManager.checkMemberAccess(java.lang.Class,int) java.lang.SecurityManager.checkSystemClipboardAccess() ...

JDK 12, Merging Collectors, and the Challenge of Naming

It appears likely that a new method will be available on the java.util.streams.Collectors class in JDK 12 that will, according to the new method's proposed Javadoc-based documentation, "Return a Collector that passes the input elements to two specified collectors and merges their results with the specified merge function." The currently proposed name of this new Collectors method is pairing , but that new method's name has been the source of significant discussion. The naming of this method has solicited wide discussion on the OpenJDK core-libs-dev mailing list . Although it would be easy at first thought to label this an example of bike-shedding (or Parkinson's Law of Triviality ), my experience has been that proper naming can be more important than it might first seem. I've seen many situations in which there was nothing wrong with the logic of a particular implementation, but problems ensued related to use of that implementation due to miscommunicati...

Project Valhalla: A First Look at L-World Value Types

Image
In the post " JVM Language Summit 2018 and Valhalla EA Build 0 ", I mentioned that Project Valhalla's "L-World Value Types" Early-Access Builds are now available for Linux/x64, macOS/x64, and Windows/x64. Specifically, " Build 0 (2018/7/30) " is available for download as a "convenience." In that same post , I also mentioned that the JVM Language Summit 2018 had just wrapped up and I provided a link to one of that event's presentations: " LWorld: the next steps on the journey to Valhalla ". In this post, I use code based on the Project Valhalla "L-World Value Types" Early-Access Build 0 to illustrate some of the points made in the JVM Language Summit 2018 presentation on early versions of L-World. CAUTION : The build discussed in this post is " intended for expert users interested in Project Valhalla ", is NOT intended for production, and has severe limitations and disclaimers associated with it. This buil...

JDK 11: Taking Single-File Java Source-Code Programs Out for a Spin

Image
The JDK 11 Early Access Builds include functionality related to JEP 330 ("Launch Single-File Source-Code Programs"). I have written about JEP 330 before in posts " Shebang Coming to Java? " and " JEP 329 and JEP 330 Proposed for JDK 11 ". I get to take this feature out for a spin in this post thanks to the JDK 11 Early Access Builds . For this demonstration, I'm using the latest (as of this writing) OpenJDK JDK 11 Early Access Build 24 . One of the first indications that support for JEP 330 is included with this JDK distribution is seen when using the -help flag ( java -help ): As shown in the last image, the "help" starts with a "usage" statement and the last example in the usage statement describes how to use the Java launcher ( java ) to run single-file source-code programs. Specifically, the output shows the following "usage" with the usage that is the subject of this post highlighted here: Usage: java [optio...