clair077

There has been concern recently that Java developers will inadvertently use the wrong Oracle-provided JDK implementation now (as of JDK 11 ) that Oracle provides builds of the open source OpenJDK and also provides commercial JDK builds based largely on the OpenJDK source. The table below compares and contrasts the two versions of JDK that Oracle provides (but Oracle won't be the only supplier of JDK builds available for free and/or for support charge). Please keep in mind this represents my best personal understanding of the differences and similarities of Oracle's two offerings; please check with an authoritative source before making decisions regarding which Oracle JDK implementation to use (or even whether to use an Oracle implementation). JDK Builds from Oracle ( https://jdk.java.net/ ) Characteristic Oracle OpenJDK Builds Oracle JDK (Java SE Downloads) Oracle's Descriptions " End users and developers looking for free JDK versions : Oracle OpenJDK ...

As scheduled, it was announced today that JDK 11 was released for General Availability . Earlier this week, Iris Clark announced the " JSR 384 (Java SE 11) Final Release " and in that same message referenced the final release version of JSR 384 , referenced the " Java SE 11 (18.9) Platform JSR (384) " specification page, and concluded, "The 384 EG is now disbanded." The " JDK 11 General-Availability Release " page provides "production-ready open-source builds of the Java Development Kit, version 11 , an implementation of the Java SE 11 Platform under the GNU General Public License, version 2, with the Classpath Exception ." That same JDK 11 GA Release page also points to "commercial builds of JDK 11 from Oracle under a non-open-source license " that are "available for a wider range of platforms" and which "can be found at the Oracle Help Center ." The " JDK 11 GA Release " page also provide...

The biggest news this week in the world of Java is likely going to be the General Availability of JDK 11 . However, another exciting development is the release of JDK 12 Early Access Build 12 ( 20 September 2018 ). This Early Access Build 12 of JDK 12 is significant because it includes implementations related to JEP 326 ["Raw String Literals (Preview)"] via changesets such as changeset 51713:d424675a9743 ( JDK-8206981 ), changeset 51714:975d3636a2f9 ( JDK-8200434 ), and changeset 51725:ccea318862ae ( JDK-8210674 ). JEP 326 itself displays multiple examples of how raw string literals might be applied in Java code in common situations (file paths, multi-line, regular expressions, database/SQL, and polyglot). These examples also appear in an arguably more readable format in associated JDK-8196004 . These "Raw String Literals" examples can be pasted into Java classes/methods and compiled successfully against JDK 12 Early Access Build 12. For convenience, I...

Several possibilities of the message's possible contents crossed my mind when I saw the title of Jesper Wilhelmsson 's message " Introducing time wasters " on the OpenJDK jdk-dev mailing list . In the second or so between reading that link and having the message appear after clicking on the link , I wondered if the message would be about one of the following topics: People wasting the time of developers working on the JDK People wasting the time of developers sharing ideas and responding to questions on the mailing lists Trivial defect reports or reports of observations that are intentional (not defects) It turns out that Wilhelmsson 's topic was more interesting than those. Wilhelmsson opens the message with these two sentences (I added the emphasis ), "As an experiment we are introducing a new label in JBS, timewaster . The label is used to tag bugs that for some reason is wasting engineering time." That message provides additional considerations to ...

An interesting question was posed in a comment on the DZone-syndicated version of my recent blog post " Arrays.hashCode() Vs. Objects.hash() ". The comment's author set up examples similar to those used in my blog post and showed different results than I saw. I appreciate the comment author taking the time to post this as it brings up a subtle nuance in Java that I think is worth a blog post. The comment author showed the following valid Java statements: int[] arr = new int[]{1,2,3,4}; System.out.println(Arrays.hashCode(arr)); System.out.println(Objects.hash(1,2,3,4)); System.out.println(Arrays.hashCode(new Integer[]{new Integer(1),new Integer(2),new Integer(3),new Integer(4)})); System.out.println(Objects.hash(new Integer(1),new Integer(2),new Integer(3),new Integer(4))); The author of the comment mentioned that the results from running the code just shown were exactly the same for all four statements. This differed from my examples where the result from calling Arra...

With General Availability of JDK 11 planned for later this month (25 September 2018), it's a good time to start looking more closely at JDK 12 . In a message titled " Proposed schedule for JDK 12 " on the OpenJDK jdk-dev mailing list , Mark Reinhold announced, "With JDK 11 nearly out the door, here's a proposed schedule for JDK 12." The schedule for JDK 12 proposed in that message includes the "Release-Candidate Phase" starting on 31 January 2019 and "General Availability" of JDK 12 on 19 March 2019. There are already two JEPs targeted for JDK 12 and both of them are " preview features " (my previous blog posts on these JEPs are listed as sub-bullets): JEP 325 ["Switch Expressions (Preview)"] " Switch Expressions Coming to Java? " " Enhancing Java switch Statement with Introduction of switch Expression " " Playing with JDK 12's Switch Expressions " " JDK 12: Switch...

Since JDK 1.5 , the Arrays class has offered overloaded static methods with the name " hashCode "​. Most of the overloaded methods accept an array of a particular primitive type, but the Arrays.hashCode(Object[]) method can be used to calculate an int hash code for an array of reference types. Since its JDK 1.7 inception , the Objects class has provided a method called hash(Object...) that also returns an int hash code for a provided array of Java objects (the ellipsis [ ... ] representing Java varargs is handled as an array and accepts an array ). This post provides a brief comparison between Arrays.hashCode(Object) and Objects.hash(Object...) . We can look at the code in OpenJDK to see how OpenJDK implements the two methods being compared here. It turns out that Arrays.hashCode(Object[]) and Objects.hash(Object...) behave exactly the same way because Objects.hash(Object...) completely delegates to Arrays.hashCode(Object[]) . This is shown in the next code list...

JEP 342 ("Limit Speculative Execution") has transitioned from " Draft " state to " Candidate " state, but it has not yet been targeted to a specific JDK release (see graphic for steps in JEP process ). Jesper Wilhelmsson has written that JEP 342 "covers the initial work to make use of new C++ compiler options to limit speculative execution in native code in the JDK." JEP 342's "Summary" succinctly describes its purpose, "Help developers and deployers defend against speculative-execution ('Spectre') vulnerabilities by providing a means to limit speculative execution, and enable further mitigations to be implemented in future releases." JEP 342 aims to provide a "distinct, alternate JVM in the JDK that is compiled with" C++ "compiler options that limit the extent to which the CPU can do speculative execution" and which "can be selected at launch time." The JEP states that the plan...

As I wrote about in my post " Playing with JDK 12's Switch Expressions ", the JDK 12 Early Access Builds have made it easy to experiment with the implementation of JEP 325 ["Switch Expressions (Preview)"]. My post " JDK 12: Switch Statements/Expressions in Action " used code examples to demonstrate core features and characteristics of the enhanced switch statement and the new switch expression . In this post, I look at a special case explicitly called out in JEP 325 related to a runtime addition to an enum used in a switch expression. Because a switch expression returns a value, it is necessary that all possible cases the switch might encounter are handled via a case (or covered by a default for those not explicitly associated with a case ). JEP 325 states the following: The cases of a switch expression must be exhaustive; for any possible value there must be a matching switch label. In practice this normally means simply that a default cl...

My last post " Playing with JDK 12's Switch Expressions " talked about use of the JDK 12 Early Access Builds to try out JEP 325 switch expressions and statements and provided a simple example. This post uses the same JDK 12 Early Access Build 10 to demonstrate different features of switch expressions and enhanced switch statements . I used a 2x2 grid in the blog post " Enhancing Java switch Statement with Introduction of switch Expression " to illustrate that the new "arrow" syntax ("switch labeled rule") can be used with a switch statement or with a switch expression per JEP 325. Similarly, per JEP 325, the traditional "colon" syntax ("switch labeled statement group") can also be used with either a switch expression or with a switch statement . In other words, presence of the colon ( : ) does NOT necessarily imply a switch statement and presence of an "arrow" ( -> ) does NOT necessarily i...

In the blog post " JDK Language Feature Preview in Action: Switch Expressions ," I discussed how JEP 325 ["Switch Expressions ( Preview )"] is an early application of a designated " preview language feature " as spelled out by JEP 12 ["Preview Language and VM Features"]. JEP 325 is targeted for JDK 12 . Even better, the Early Access Builds for JDK 12 already provide support for this preview language feature! I've been excited about the possibilities associated with switch expressions as demonstrated in my previous blog posts " Switch Expressions Coming to Java? ", " Enhancing Java switch Statement with Introduction of switch Expression ", and the aforementioned " JDK Language Feature Preview in Action: Switch Expressions ." The JDK 12 Early-Access Builds make it really easy to start experimenting with this preview language feature and I demonstrate this using JDK 12 Early Access Build 10 (2018/9/6) [latest ...