Java's Future-Looking Projects: Panama, Loom, Amber, and Valhalla

The press release "Oracle Code One Java Keynote Outlines the Future of Java" describes the Java Keynote at Oracle Code "highlight[ing] future projects" Project Valhalla, Project Panama, Project Amber, and Project Loom. This post provides brief summaries of each of these projects and some recent work associated with each of these projects for those who may not be familiar with the mentioned projects.

Project Panama

Project Panama is about "Interconnecting JVM and native code." Its introduction states, "We are improving and enriching the connections between the Java TM virtual machine and well-defined but 'foreign' (non-Java) APIs, including many interfaces commonly used by C programmers."

Build 0 (2018/10/24) of the Project Panama Early-Access Builds was released recently. As with other OpenJDK-related early access builds, this build is "intended for expert users" and "is provided as a convenience so that they don't need to build from the source code." One of its most significant issues to be aware of is, "Windows support not available."

Project Loom

The Project Loom page describes Loom: "The goal of this Project is to explore and incubate Java VM features and APIs built on top of them for the implementation of lightweight user-mode threads (fibers), delimited continuations (of some form), and related features, such as explicit tail-call."

The Project Loom proposal (titled "Project Loom: Fibers and Continuations for the Java Virtual Machine") begins, "Project Loom's mission is to make it easier to write, debug, profile and maintain concurrent applications meeting today's requirements."

The message "Kick off meeting for Project Loom" on the OpenJDK loom-dev mailing list states that "Project Loom has been up and running here for number of months doing some early exploration and prototyping of both delimited continuations and fibers." That message talks about expanding that effort with kick-off meeting and provides links to the aforementioned Project Loom Proposal and to the YouTube-hosted presentation "Project Loom with Ron Pressler and Alan Bateman."

Project Amber

The Project Amber page describes its goal "to explore and incubate smaller, productivity-oriented Java language features that have been accepted as candidate JEPs under the OpenJDK JEP process." There are some exciting features being explored via this project including Pattern Matching (JEP 305), Switch Expressions (JEP 325), Raw String Literals (JEP 326), Concise Method Bodies (draft JEP), and faster String.format and Objects.hash methods [JDK-8205637 ("Optimized invocation of String::format and Objects::hash")].

The list of JEPs just mentioned are evidence of the significant work underway on Amber.

Project Valhalla

All of these projects propose exciting additions to Java, but the one I'm most excited about is Project Valhalla and its Value Objects/Types (JEP 169). The Project Valhalla page describes this project's goal "to provide a venue to explore and incubate advanced Java VM and Language feature candidates."

Project Valhalla has seen significant developments in recent weeks, especially since and as a result of the Valhalla Executive Group Meeting on 10 October 2018. In the OpenJDK valhalla-spec-experts mailing list message "Entering the next phase of Project Valhalla," Brian Goetz writes that this meeting was a "super-productive meeting with broad attendance" that helped Valhalla developers "to thrash out where we are, and where we're going next." Goetz also states that "this marks the beginning of the Phase III of the project" and outlines what constituted Phase 1 and Phase 2. This same packed message also summarizes the next steps for Valhalla:

Looking ahead, our next target is L2 -- which will capture the choices we've made so far, provide a useful test bed for doing library experiments, and set the stage for drilling into the remaining open questions between here and L10. L10 is our target for a first preview, which should support value types and erased generics over values.

Another recent interesting Goetz message on the valhalla-spec experts mailing list is "Values and erased generics," in which Goetz provides a "a summary of the story we came up with for erased generics over values" that "builds on the typing story outlined in John's 'Q-Types in L-World' writeup." The title of that referenced John Rose writeup is currently, "Q-Types in L-World 10: Valhalla Working Group, Burlington, September 2018." A revision of proposed JVM specification changes for LW2 was announced earlier this month as well.

The amount of work being done related to Project Valhalla is made clear in the number of messages on the mailing list about this project. These include those previously mentioned as well as others such as "var, static factory method and value type constructor"; "Value types, encapsulation, and uninitialized values"; and "Array covariance".

There is also a series of Goetz messages focusing on specific lessons learned from the first two phases:

• "[LW100] Specialized generics -- translation and binary compatibility issues"
  • "Challenges of evolving a class to be any-generic, while interacting with existing erased code."
• "[LW100] Specialized generics -- migration"
  • "Stories we cooked up for migration."
• "[LW100] Specialized generics -- user model issues"
  • "User model and source compatibility of migrating existing libraries"
• "[LW10] Value equality"
  • "If we expect values to 'work like an int', then |==| comparisons on value types should work like they do on primitives..."

The OpenJDK valhalla-dev mailing list message "Valhalla project repository status: Branched off 'LW1' in preparation for 'LW2'" announces the creation of the "lw1" branch.

Conclusion

It's not surprising that these four projects were mentioned at Oracle Code One's Java Keynote. They cover many of the features to look forward to in Java's future.

IBM to Acquire Red Hat: A Java-Oriented First Look

Oracle Corporation completed the process of acquiring Sun Microsystems nearly nine years ago. That was big news then and similarly big news was announced today: IBM and Red Hat have agreed to IBM's acquisition of Red Hat. The main IBM page announces "IBM to acquire Red Hat." It then states, "This changes everything." It is likely that this announced acquisition is going to leave many Java developers wondering what kinds of changes are coming to the Java ecosystem.

Since Oracle's acquisition of Sun Microsystems, Oracle has eliminated multiple products that were formerly competitive products. For example Oracle still has its JDeveloper IDE, but has provided NetBeans (acquired from Sun) to Apache Software Foundation. Oracle has also dropped commercial support for Sun-acquired GlassFish while retaining its WebLogic Java EE application server.

I, of course, have no idea what will happen to the products and tools available to Java developers as currently provided by IBM and Red Hat. However, there are some obvious overlaps that come to mind from this $34 billion (USD) acquisition.

Item	Red Hat	IBM
JDK Builds/Binaries	OpenJDK	IBM SDK / AdoptOpenJDK
Java EE Application Server	JBoss / Wildfly	WebSphere / Liberty
OpenJDK Support/Contributions	OpenJDK Life Cycle and Support Policy	IBM Supporting the Java Community
Java Community Process (JCP) Executive Committee (EC)	Mark Little (Scott Stark alternate)	Steve Wallin (Tim Ellison alternate)
Integrated Development Environment (IDE)	Eclipse-based Red Hat JBoss Developer Studio	Eclipse-based IBM Rational Application Developer for WebSphere

Both IBM's version and Red Hat's version of the acquisition press release (which share much of the same wording) state, "With this acquisition, IBM will remain committed to Red Hat's open governance, open source contributions, participation in the open source community and development model, and fostering its widespread developer ecosystem." Perhaps even more encouraging, the press releases also state, "Upon closing of the acquisition, Red Hat will join IBM's Hybrid Cloud team as a distinct unit, preserving the independence and neutrality of Red Hat's open source development heritage and commitment, current product portfolio and go-to-market strategy, and unique development culture. ... IBM intends to maintain Red Hat's headquarters, facilities, brands and practices."

Both IBM and Red Hat are significant contributors to OpenJDK and to Java in general. Therefore, it should not be surprising if Java developers wonder how this acquisition will affect these two organizations' respective contributions.

At the very least, I image the question "Why choose JBoss Enterprise Middleware over IBM WebSphere?" likely won't remain on the JBoss page after this acquisition.

Book Review: Java by Comparison

I accepted the invitation to review Java by Comparison: Become a Java Craftsman in 70 Examples (2018, The Pragmatic Bookshelf) because the premise of this book interested me. The book Software Craftsmanship: The New Imperative had a significant effect on me when I was a much less experienced software developer and I looked forward to reviewing Java by Comparison because of its connection with the concept of software craftsmanship and its examples being provided in the Java programming language. I was provided with the electronic version of the book and I chose the PDF format for my review.

Java by Comparison is written by Simon Harrer, Jörg Lenhard, and Linus Dietz and has over 160 pages of substantive content (not counting prefaces, forewords, table of contents, etc.). Java by Comparison features nine chapters and the 70 cases covered span the first eight of those nine chapters.

Java by Comparison uses the same format for eight of its nine chapters. Each of these eight chapters are divided into several items each and at least two code samples are presented for each item. The first code sample for each item is typically functionally correct code, but the second code sample for each item illustrates how that particular item's principle can be applied to improve that code. There are three samples of these items ("extracts") available on the book's web site to see what I'm attempting to explain here.

Java by Comparison covers specific principles that fall into the areas of clean code, stylistic considerations, readability considerations, comments, naming, exception handling, unit testing, object-oriented design, and using Java's functional capabilities that were largely introduced to the language with JDK 8. Simple code examples are used in each item to contrast minimally sufficient code with improved code.

The ninth and final chapter is different from the first eight chapters. That chapter has fewer code samples and more descriptive text of general practices experienced Java developers tend to adopt in areas such as static code analysis, build automation, continuous integration, logging, and working with concurrency. This chapter is mostly higher-level and provides a taste of these topics for the newer Java developer.

I consider the following to be strengths of Java by Comparison:

• Content
  • Java by Comparison collects information useful to newer Java developers in a single location.
  • As Java by Comparison covers various topics, it also introduces useful side notes of value to newer Java developers. Here are some examples of this:
    • There is a side note about "Multiple Returns vs. Single Return per Method" in the section on avoiding unnecessary comparisons.
    • There is a side note about "Never Use Floating-Point Arithmetic for Money" in the section on using appropriate tolerance values in unit testing.
  • Java by Comparison uses several different parts of the JDK API to illustrate its points.
  • Most of the lessons discussed in Java by Comparison are ones that I've had to learn the hard way and I found myself agreeing with most of the recommendations (and I've even blogged on some of them).
• Format
  • The format comparing working code with superior code is effective in illustrating the principle discussed in each item.
  • The authors find a nice balance of small, simple code examples and just enough text to cover the point.
• Finish
  • Java by Comparison is polished and has very few grammatical errors or typos. This seems to be an increasingly rare characteristic of technical books.
  • Code listings have color-coded syntax and shaded background in the PDF version of the book.
  • PDF version provides links between pages that reference each other.
  • Links to online resources work from PDF.
  • An accessible errata is available.
• Tone
  • The text in Java by Comparison is easy to read, highly approachable, succinct, and well suited for those newer to Java.
  • Java by Comparison makes recommendations, but is not overly prescriptive and on several occasions highlights that sometimes "best" is context-sensitive and can only be determined after trying different approaches.
  • Although written by three different authors, the writing of Java by Comparison is consistent and uniform.
• References
  • Java by Comparison provides frequent references to books and online resources for additional details regarding the concepts it covers.
  • Java by Comparison's "Bibliography" lists several of the most influential books and posts in Java and software development.

Intended Audience

I would have liked to have had access to Java by Comparison when I was still relatively new to Java. I remember reading the first edition of Effective Java and learning some from it, but Java by Comparison would have been more appropriate for my level of comfort with Java at that time.

The "Acknowledgements" section of Java by Comparison provides insight into the intended audience. The authors started building "a collection of common issues" that students in their "Advanced Java Programming" class encountered. The "Who Should Read This Book" section of the book addresses the audience more directly, "This book is for people who are learning to program in Java at a beginner or intermediate level. It's also a classroom resource for teachers who coach new developers in their journey to become programmers." The authors add, "You should read this book after you’ve learned the basic Java syntax - after you're able to write small programs with conditions and loops and you know the basics of object-oriented programming." The authors even provide a FizzBuzz-based assessment for potential readers to determine if they have the minimum recommended Java ability to make this book useful to them.

I agree with the authors' recommendations regarding who will benefit most from Java by Comparison. However, I would add that even more experienced Java developers might benefit greatly from reading Java by Comparison if they have not spent much time reading things such as Effective Java, Clean Code, Holub on Patterns, or other books or online media regarding writing Java more effectively.

My Recommendation

Many developers new to Java who have started feeling comfortable with its syntax and basic APIs often ask what is the next best book from them to read. Java by Comparison now gives me an easy answer to that question. I will recommend this book to developers new to Java as an appropriate book for them to read before moving onto Clean Code and Effective Java.

Java by Comparison is also recommended for more experienced Java developers who have concentrated mostly on getting the job done in the past and would like to do a better job at writing code that is more than sufficient and is easier for the next developer who has to work with it.

Java by Comparison applies a novel approach to presenting ideas for beginning and intermediate Java developers to learn techniques they can practice to become better Java developers and to write better code that will benefit others and themselves.

Additional References

There are three sample "excerpts" available to give a prospective reader an opportunity to determine if he or she likes the format and style of writing. There are listed below. I have also included links to others' reviews of Java by Comparison because we all have different tastes and experiences and it might be helpful for prospective readers of Java by Comparison to read what others have said about the book.

• Java by Comparison's Table of Contents features freely available sample sections:
  • Preface ("Welcome!")
  • "Return Boolean Expressions Directly"
  • "Document Using Examples"
  • "Split Method with Boolean Parameters"
• Other reviews of Java by Comparison
  • I Programmer's Java by Comparison
  • Dr. Frank Raiser's Book Review: Java by Comparison
  • Alexander Schwartz's Book Review: Java by Comparison
  • Quinn Gil's Book Review: Java by Comparison
  • Philip Riecks's #REVIEW: Java by Comparison
  • One of Thorben Janssen's 5+2 Books Every Java Programmer Should Read in Summer 2018

JDK 12 News (4 October 2018)

There has been significant news related to JDK 12 in recent days.

JDK 12 Early Access Build 14

JDK 12 Early Access Build 14 (2018/10/4) was released today. The release notes indicate that the fix for JDK-8210692 ["The 'com.sun.awt.SecurityWarning' class can be dropped"] is a significant part of this build. The class com.sun.awt.SecurityWarning, deprecated for removal with JDK 11, has now been removed altogether. Other links of interest related to OpenJDK 12 Early Access Build 12 include "Changes in this build" and "Issues addressed in this build". This build also includes, of course, the preview features switch expressions (JEP 325) and raw string literals (JEP 326) that I have blogged on previously.

JEP 340 Targeted for JDK 12

Mark Reinhold announced in the post "JEP proposed to target JDK 12: 340: One AArch64 Port, Not Two" that JEP 340 ["One AArch64 Port, Not Two"] is now targeted for JDK 12.

JEP 341 Targeted for JDK 12

Reinhold also announced in "JEP proposed to target JDK 12: 341: Default CDS Archives" that JEP 341 ["Default CDS Archives"] is also targeted for JDK 12.

JDK 12 Proposed Schedule Approved

In a third consecutive message on the OpenJDK jdk-dev mailing list, Reinhold announced in the message "Proposed schedule for JDK 12" that the proposed schedule for JDK 12 has been approved. General Availability of JDK 12 is currently planned for 19 March 2019. As of this writing, there are now four JEPs targeted for JDK: JEP 325, JEP 326, JEP 340, and JEP 341.

A Tale of Two Oracle JDKs

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 offers the same features and performance as Oracle JDK under the GPL license."	"Oracle Customers and ISVs targeting Oracle LTS releases: Oracle JDK is Oracle's supported Java SE version for customers and for developing, testing, prototyping or demonstrating your Java applications."
Web Address	https://jdk.java.net/11/	https://www.oracle.com/technetwork/java/javase/downloads/jdk11-downloads-5066655.html
License	GNU General Public License, version 2, with the Classpath Exception	Oracle Technology Network License Agreement for Oracle Java SE
Build Platforms (Binaries)	Linux / x64 (tar.gz) macOS / x64 (tar.gz) Windows / x64 (zip)	Linux / x64 (tar.gz, deb, rpm) macOS / x64 (tar.gz, dmg) Windows / x64 (zip, exe) Solaris SPARC (tar.gz)
Pay for Production Use	No	Yes
Oracle Support	Select bug fixes and security patches until next JDK version's General Availability release	Java SE Subscription (Support for LTS versions for up to 8 years)
		Several Other Paid Support Offerings under "Oracle Customers"
java -version Example	openjdk version "11" 2018-09-25 OpenJDK Runtime Environment 18.9 (build 11+28) OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)	java version "11" 2018-09-25 Java(TM) SE Runtime Environment 18.9 (build 11+28) Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11+28, mixed mode)
Required to Accept License Agreement	No	Yes
Java Flight Recorder	Yes	Yes
Java Mission Control	Yes	Yes
Advanced Management Console	No	Yes
This table represents my personal understanding only; refer to Oracle documentation and OpenJDK documentation for more authoritative information (see "References" below).

There are other implementations of the JDK that will be available as well, with some being free and some requiring payment. I did not discuss those alternatively provided JDKs in this post in order to keep the comparison cleaner and simpler between the "Oracle OpenJDK builds" and the "Oracle JDK builds".

References

• Oracle Java SE Support Roadmap
• Oracle JDK Releases for Java 11 and Later
• Java SE Offerings
• Update and FAQ on the Java SE Release Cadence
• OpenJDK Trademark Notice (Oracle owns the trademark)

JDK 11 General Availability

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 provides links to the detailed JDK 11 Release Notes, to the list of features (JEPs) associated with JDK 11, to the Java SE/JDK Version 11 API Specification (Javadoc), and to the Java SE 11 Tools and Command Reference.

In the message "Java 11 / JDK 11: General Availability", Mark Reinhold writes:

JDK 11, the reference implementation of Java 11 and the first long-term support release produced under the six-month rapid-cadence release model[1][2], is now Generally Available. We've identified no P1 bugs since we promoted build 28 over four weeks ago so that’s the official GA release, ready for production use.

JDK 11 is significant for several reasons, not the least of which is its status as the basis for Oracle's LTS offering and the likelihood of this being the version of Java many shops will move to if they are currently on Java 8. An interesting read along these lines for those who do not intend to purchase commercial support for Oracle JDK implementations is "The future of Java and OpenJDK updates without Oracle support." Other recent posts that are probably worth reading in light of JDK 11's release are "Oracle JDK Releases for Java 11 and Later", "Java Is Still Free", and "Introducing Java SE 11".

Oracle's "Java SE Development Kit 11 Downloads" page highlights (in orange-ish background and with emphasized title "Important changes in Oracle JDK 11 License") the "substantially different" Oracle Technology Network License Agreement that now applies to Oracle Java SE and provides a link to "this software under the GPL License on jdk.java.net/11" (Oracle's OpenJDK builds).

Raw String Literals Support in JDK 12 Early Access Build 12

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've placed slightly adapted versions of these in a single Java class on GitHub.

Note that JEP 326 is a "Preview Feature", so you must compile with the javac options --enable-preview and --release 12 or else you'll encounter the error message, "error: raw string literals are a preview feature and are disabled by default" with a pointer to the backtick used to demarcate the raw string literal. Similarly, the code must be run with java launcher option --enable-preview to run successfully and to avoid the error message, "... UnsupportedClassVersionError: Preview features are not enabled ..."

As far as I can determine, Early Access Build 12 does not include an implementation for JDK-8202442 ["String::unescape"]. Some of the library methods added to the String class related to raw string literals are part of JDK 11 and I discussed some of these in the post "Applying New JDK 11 String Methods".