Posted on

Total Bummer: Pivotal Drops Groovy

Pivotal announced yesterday that Groovy 2.4 And Grails 3.0 will be the last major releases under Pivotal sponsorship. This is big news that has not surprisingly created a lot of buzz in the blogosphere. In this post, I describe some of the questions that others and I are wondering about and speculate on Groovy's future.

Groovy’s Future is in Doubt

Sadly, it appears at this time that is more likely than not that Groovy does not have a significant future ahead. It would seem that the developers of this program are going to allow it to rot away instead of taking any action steps to potentially stave off such an outcome. 

Posted on

The Challenges of a JavaFX Reboot

In Jonathan Giles's post An FX Experience Retrospective, he starts by looking at the history of JavaFX and focuses on "what has happened in the world of JavaFX" in 2011. I was highly skeptical of JavaFX prior to JavaOne 2010 (see here and here for examples), but started to think more positively about it after the JavaOne 2010 and JavaOne 2011 announcements related to JavaFX. 

One thing that has been a little tricky about learning JavaFX since JavaOne 2011's big announcements have been knowing for certain whether a particular resource on JavaFX applies to JavaFX 1.x or JavaFX 2.x. Reading the An FX Experience Retrospective post provided a different perspective on the risks and challenges Oracle and the JavaFX team has faced in making this major overhaul.

Posted on

JDK 17: Hexadecimal Formatting and Parsing

Build 3 of JDK 17 Early Access Builds includes the implementation for JDK-8251989 ("Hex formatting and parsing utility"). This newly introduced functionality for parsing and formatting hexadecimal values is encapsulated in the new class java.util.HexFormat and is the subject of this post.

Running javap against the new java.util.HexFormat class provides an easy way to see an overview of its API. The following output is generated from running javap java.util.HexFormat:

Posted on

General, Safe, and Deterministic Foreign Memory Access in JDK 14

Let's look at the numerous JDK 14-targeted features available, specifically the Foreign Memory API.

In the post "JDK 14 Rampdown: Build 27," I summarized the numerous JDK 14-targeted features newly available with JDK 14 Early Access Build #27. There is already another JDK 14 Early Access Build available and this one [ Build 28 (2019/12/18)] includes one particularly interesting feature: Enhancement JDK-8234049 ["Implementation of Memory Access API (Incubator)"].

Posted on

JDK 14: Records, Text Blocks, and More

Learn more about these five new proposed JEPs targeted for JDK 14.

On Monday, Mark Reinhold's post "JEPs proposed to target JDK 14: 305, 343, 359, 366, & 368" proposed targeting five more JEPs to JDK 14. Some highly anticipated features are among this group, although all but one are proposed to be in "preview" or "incubating":

  • JEP 305: Pattern Matching for instanceof (Preview)
  • JEP 343: Packaging Tool (Incubator)
  • JEP 359: Records (Preview)
  • JEP 366: Deprecate the ParallelScavenge + SerialOld GC Combination
  • JEP 368: Text Blocks (Second Preview)

The Java SE 13 Java Language Updates document describes preview features (JEP 12): "A preview feature is a new feature whose design, specification, and implementation are complete, but which is not permanent, which means that the feature may exist in a different form or not at all in future JDK releases."

Posted on

JDK 14: CMS GC Is OBE

JDK 14 Early Access Build #23 is now available.

JDK 14 Early Access Build #23 ( 2019/11/13) is now available. One of the more noteworthy changes with this build is the removal of the Concurrent Mark Sweep garbage collector. JEP 291 ["Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector"] deprecated the Concurrent Mark Sweep (CMS) garbage collector back in 2017 with JDK 9 and JEP 363 ["Remove the Concurrent Mark Sweep (CMS) Garbage Collector"] has been targeted for JDK 14 to remove the CMS garbage collector altogether.

The next screen snapshot demonstrates that the CMS garbage collector was still available with JDK 14 Early Access Build #22.

Posted on

Six More JEPs Proposed for JDK 14

Check out the newest proposals for JDK 14!

A recent Mark Reinhold message announces six new "JEPs proposed to target JDK 14": JEP 345, JEP 361, JEP 363, JEP 364, JEP 365, and JEP 367. Assuming no objections are made by November 7, these JEPs will be targeted to JDK 14 along with previously targeted JEPs JEP 349 ("JFR Event Streaming"), JEP 352 ("Non-Volatile Mapped Byte Buffers"), and JEP 358 (" Helpful NullPointerExceptions"). This post summarizes each of these six JEPs proposed for targeting JDK 14.

JEP 345: NUMA-Aware Memory Allocation for G1

The succinct "Summary" of JEP 345 states, "Improve G1 performance on large machines by implementing NUMA-aware memory allocation." Two important "non-goals" of this JEP indicate that the JEP is only intended to add NUMA (non-uniform memory access) support to the G1 garbage collector and only for Linux. However, the JEP also points out that "the parallel collector, enabled by -XX:+UseParallelGC, has been NUMA-aware for many years."

Posted on

Sealed Types: JLS Changes (Draft)

OpenJDK recently announced a new draft language spec for sealed types

Following the recent announcement of the candidate JEP on sealed types (preview), Gavin Bierman's message "Draft JLS spec for sealed types" on the OpenJDK amber-spec-experts mailing list announces "a draft language spec for sealed types" and provides a link to that draft. That message also states: "This spec doesn't yet contain details on binary compatibility (Chapter 13) — to appear in the next draft."

You may also like: Candidate JEPs: Records and Sealed Types 

In this post, I highlight some of the proposed changes to the Java Language Specification (JLS) for sealed types. It is important to keep in mind the tentativeness of these proposed changes: this is an of JLS changes for a feature associated with a JDK Enhancement Proposal (JEP).

Posted on

Candidate JEPs: Records and Sealed Types

Changes to records and sealed types were proposed in the most recent JDK Enhancement Proposals

Mark Reinhold announced two new closely related candidate JDK Enhancement Proposals (JEPs) on the OpenJDK amber-dev mailing list this week with the posts "New candidate JEP: 359: Records (Preview)" and " New candidate JEP: 360: Sealed Types (Preview)." Both of these candidate JEPs are "preview features" (defined by JEP 12).

In other JDK news: java.lang.Records: Draft Specification

JEP 359: Records (Preview)

The JEP 359 "Summary" states, "Enhance the Java programming language with records. Records provide a compact syntax for declaring classes which are transparent holders for shallowly immutable data."

Posted on

Project Valhalla: A First Look at LW2 Inline Types

I summarized some recent Project ValhallaLW2 "inline types" progress that was made public recently in my blog post "Valhalla LW2 Progress - Inline Types." In this post, I illustrate some of the concepts summarized in that post with code examples executed against recently released Valhalla Early Access Build jdk-14-valhalla+1-8 (2019/7/4). All code examples featured in this post are available on GitHub.

The OpenJDK Wiki page "LW2" provides an illustrative example of inline types via source code for a class called "InlineType." My example makes some minor adaptions and additions to this class and is available on GitHub as a class called InlineTypeExample. Some items that stand out immediately when reviewing this source code are the presence of the keyword inline and the presence of the ? in the Comparable's generic parameter.

Posted on

Signs of JDK 14 Beginning to Appear

JDK 13 is currently in Rampdown Phase 1 (RDP 1), is scheduled to enter Rampdown Phase 2 (RDP 2) in a little over one week (on July 18, 2019), and is tentatively scheduled for General Availability on September 17, 2019. What this means, of course, is that it's time to start thinking about JDK 14! This post references and summarizes some of the online resources related to JDK 14 that are starting to appear.

Project JDK 14

The main OpenJDK JDK 14 page is the best place to start when wishing to see an overview of the release and its progress. Besides a reference to its associated specification (JSR 389: "Java SE 14 Platform"), the only other information available on this page as of this writing is a simple "Status" paragraph that references development repositories and the JDK Enhancement Proposal (JEP) process.

Posted on

A New Era for Determining Equivalence in Java?

Liam Miller-Cushon has published a document simply called "Equivalence" in which he proposes "to create a library solution to help produce readable, correct, and performant implementations of equals() and hashCode()." In this post, I summarize some reasons why I believe this proposal is worth reading for most Java developers, even if the proposal never gets implemented, and why the proposal's implementation would benefit all Java developers if realized.

Miller-Cushon opens his proposal with a single-sentence paragraph: "Correctly implementing equals()  and hashCode() requires too much ceremony." The proposal points out that today's powerful Java IDEs do a nice job of generating these methods, but that there is still code to be read and maintained. The proposal also mentions that "over time, these methods become a place for bugs to hide." I have been on the wrong end more than once of particularly insidious bugs caused by an error in one of these methods and these can be tricky to detect.

Posted on

OpenJDK on GitHub

Project Skara was created "to ... investigate alternative SCM and code review options for the JDK source code, including options based upon Git rather than Mercurial, and including options hosted by third parties." The OpenJDK skara-dev mailing list included a post from Robin Westberg last week that announced, "We have added some additional read-only mirrors of a few different OpenJDK project repositories to the https://github.com/openjdk group..."

The read-only OpenJDK repositories on GitHub will likely be more convenient for developers wanting to take advantage of the "open source" nature of OpenJDK to take a peek at its internals. More developers are likely to be comfortable with Git than with Mercurial. The GitHub-hosted repositories make it even easier to clone a given repository or to even fork it.

Posted on

April 2019 Update on Java Records

After Project Valhalla's "Value Types/Objects," the language feature I am perhaps the most excited to see come to Java is Project Amber's "Data Classes" (AKA "Records"). I wrote the post "Updates on Records (Data Classes for Java)" about this time last year and use this post to provide an update on my understanding of where the "records" proposal is now.

A good starting point for the current state of the "records" design work is Brian Goetz's February 2019 version of "Data Classes and Sealed Types for Java." In addition to providing background on the usefulness of "plain data carriers" being implemented with less overhead than with traditional Java classes and summarizing design decisions related to achieving that goal, this post also introduces noted Java developer personas Algebraic Annie, Boilerplate Billy, JavaBean Jerry, POJO Patty, Tuple Tommy, and Values Victor.

Posted on

Stashing Previously Set psql Variables

The command-line based "PostgreSQL interactive terminal" known as psql is handy for manipulating and accessing data in a PostgreSQL database. Because of its command-line nature, psql is particularly well-suited for use in scripts. One of the psql features that makes it even more useful in scripting contexts is its support for "meta-commands." As the psql documentation states, "Anything you enter in psql that begins with an unquoted backslash is a psql meta-command that..." and "...these commands make psql more useful for administration or scripting."

When writing psql scripts, it is often preferable to set some variables locally for the time period that the script is being run but might also be desirable to not change these variables permanently for the psql session if it's likely that other scripts or other work will be performed from the psql session after the script's conclusion. In this post, I will demonstrate use of psql's \set meta-command to temporarily store off previous settings of variables to restore these settings at the script's conclusion.

Posted on

jcmd, Circa JDK 11

Nicolas Fränkel recently published a survey of command-line tools delivered with OpenJDK 11 in the blog post "OpenJDK 11, tools of the trade." In that post, he briefly summarizes the tools jps (a JVM process status tool), jinfo (JVM configuration details), jmap (classes/objects on the heap), jstack (thread analysis), and graphical tool JConsole (monitor Java applications).

All of these tools are handy for Java developers to be aware of to apply as needed and Fränkel's post provides a nice introductory overview for those new to these tools. In recent years, I've moved toward applying the single jcmd tool instead of most of the other command-line tools (though it doesn't replace graphical tool JConsole in any way) as I've discussed in the post " jcmd: One JDK Command-Line Tool to Rule Them All."

Posted on

Revealing the Queries Behind Psql’s Backslash Commands

PostgreSQL's psql interactive terminal tool provides several useful "backslash list commands" such as \d (lists "relations" such as tables, views, indexes, and sequences), \dt (lists tables), \di (lists indexes), \ds (lists sequences), \dv (lists views), \df (lists functions), \du (lists roles), and \? (displays help/usage details on backslash commands). These commands are concise and much simpler to use than writing the queries against PostgreSQL system catalogs ( pg_class, pg_roles, pg_namespace, pg_trigger, pg_index, etc.) and information_schema that would provide the same types of details.

Although the psql backslash commands are easier to use than their associated queries, there are situations when it is important to know the full query behind a particular command. These situations include needing to perform a slightly different/adapted query from that associated with the pre-built command and needing to perform similar queries in scripts or code that are being used as PostgreSQL clients instead of psql. These situations make it important to be able to determine what queries psql is performing and the psql option -E (or --echo-hidden) allow that.

Posted on

JDK 9/JEP 280: String Concatenations Will Never Be the Same

JEP 280 ("Indify String Concatenation") was implemented in conjunction with JDK 9 and, according to its "Summary" section, "Change[s] the static String-concatenation bytecode sequence generated by javac to use invokedynamic calls to JDK library functions." The impact this has on string concatenation in Java is most easily seen by looking at the javap output of classes using string concatenation that is compiled in pre-JDK 9 and post-JDK 9 JDKs.

The following simple Java class named "HelloWorldStringConcat" will be used for the first demonstration.