Amazon Corretto, JDK Development, And Event-Stream

CodeFX Occasionally #67–30th of November 2018

Nicolai Parlog
Dec 5, 2018 · 7 min read

Hi everyone,

Quite a few things happened recently or are upcoming and I didn’t manage to squeeze all of them into this newsletter. I could fit in Amazon’s open JDK, developments in upcoming Java versions, and a quick summary of the event-stream disaster.

Looks like I should write more often. 😉

I send this newsletter out some Fridays. Or other days. Sometimes not for weeks. But as an actual email. So, subscribe!


Amazon Corretto — open JDK, long-term support, free of charge

Out of left field, a new player entered the game! Amazon now offers Amazon Corretto, a GPL+CE-licensed OpenJDK build with free long-term support. Here are the key information:

  • based on OpenJDK, plus security/performance/stability/bug fixes implemented by Amazon
  • support for Linux, macOS, Windows
  • free to use, GPL+CE licensed
  • long-term support for Java 8 until at least 2023
  • long-term support for Java 11 starting in 2019 until at least 2024
  • quarterly updates with possible intermittent urgent fixes

Regarding contributions to OpenJDK, the FAQ says, that “Amazon started contributing to OpenJDK in 2017 and […] plan[s] to increase contributions in both number and complexity.” I guess/hope that means that Amazon will work to upstream their fixes into OpenJDK, so they become available for everybody.

This is supported by tweets like this one from Arun Gupta, a Principal Technologist at Amazon Web Services:

Everything in #Corretto today is either contributed upstream to #OpenJDK or is filed as an issue and attached as a patch. Upstream compatibility is of utmost importance to #Corretto.

If I didn’t miss something, this implies that Amazon will merge Oracle’s fixes from the main development line into the freely accessible Corretto 11 code base and then work to include those patches in the OpenJDK 11 repo. This makes a free, long-term supported, community-driven OpenJDK 11 very likely!


Posts, videos, and trainings

Here’s what I’ve published since we’ve last spoken:

I’m currently working on a cheat sheet for building and running modular JARs from the command line. I don’t expect the general public to be particularly interested in this, but it should help developers in my module system trainings. To really get to know the module system, you need to compile, package, and launch from the command line, but most devs don’t have a lot of experience with this (I surely didn’t before experimenting with the JPMS). The cheat sheet should make that easier.

Looking forward, I will be giving a vJUG presentation on experiments with var (based on these articles) on December 12th (we moved it, so Stuart Marks could give his var introduction first). I've also begun to ramp up my trainings:

If you register for the trainings in Stockholm now, you’ll get a 15% discount.


Evolving Java

Java continues to move forward. Here are a few of the things that were recently discussed, proposed, or implemented.

Uninitialized Values

Project Valhalla discusses how to represent uninitialized values. Sure, an uninitalized Point or Complex can be all zeros, but there is a worry that this does now work well for all value types and that for some "all zeros" is even incorrect (Instant is given as an example, although I don't understand why).

Brian Goetz lists the following options:

* Zeroes. This is simple but sharp-edged; any value could be zeroes, and both clients and value class implementors have to deal with this forced-on-you value, no matter how ill-suited it may be to the domain.

* User-provided. Here, the no-arg constructor is consulted (if present, wave hands about what happens when it is not a pure function). Values are not nullable, but every value is the result of running a constructor, so users are not surprised by seeing a value that was invisibly manufactured. But, every value class that cares has to still implement some sort of “null object pattern” for itself. Which may or may not be a burden (C#’s experience suggests it’s not too bad.)

* Nullable. Here, after suitable opt-in, null is made to appear to be a member of the value set for the class, and this is the default value. Dereferencing a null results in a NPE.

* Vullable. This is like nullable, but somehow specific to values.

For a comprehensive writeup of the problem, check Nullable Value Types in L-World by Brian Goetz and John Rose.

Public Classes Per File

The JDK team is considering the addition of so-called sealed types. A sealed type is a type with a fixed set of subtypes. Think of a tree-representation of simple arithmetic formulas, where you have a supertype ArithmeticNode (say an interface) with the subtypes AdditionNode and ConstantNode. It may make sense to treat ArithmeticNode as a sealed typed and forbid further implementations.

A use case for this is exhaustive pattern matching, when you match on the parameter’s type (not yet possible in Java):

switch (node) {
case instanceof AdditionNode a -> /* do something */;
case instanceof ConstantNode c -> /* do something */;
// compiler knows there are no other subtypes
// ~> no `default` branch needed
}

The question that arises is how to organize a sealed type and its subtypes in Java. In Kotlin, for example, they are all placed as public, top-level classes in the same source file. That doesn’t work in Java, though, but there’s been a discussion on the mailing list whether it should.

Stream Improvements

There are three improvements to the stream API that I hope to see in future versions:

  • the Stream method toList() as shortcut for collect(toList()) to make the most common case really easy (JDK-8180352; scheduled for 12, but not yet implemented)
  • the Iterator method stream() to "not have to rummage around in StreamSupport" (JDK-8181054; fix version to be determined)
  • some operation “to extract the only element from a stream” as I argue in this post on findFirst and findAny (JDK-8201273; unclear whether this will happen at all)

Let’s see what and when we get any of that.

Documenting System Properties

A smaller and (less contentious) change is the improved documentation for system properties. The following has been announced on the jdk-dev mailing list:

JDK 12 introduces a new inline javadoc tag, @systemProperty /property-name/ which can be used to "declare" the name of a system property. You can use this tag as a drop-in replacement for the plain-text property name; it will have no overt effect on the narrative text, but it will cause the property name to be put into the search index and the A-Z index. Thus, property names will become searchable, to allow users to easily find the definition of any such system property.

It goes on:

Now that the support is in javadoc, we want to update the API documentation, so that the documentation is updated for all Java SE and JDK system properties.


Event-Stream Disaster

Did you hear about the event-stream disaster? The original developer of the fairly popular event-stream library handed over control of the project to a bad actor who introduced an attack that tried to steal bit coins.

This is a really interesting case with lots of different aspects. Here are a few related links:

Apparently, event-stream’s developer stopped maintaining the library a while ago; he didn’t use it himself anymore and saw no reason to provide free support for others (which I totally understand). When he was approached by the bad actor who offered to maintain the project he agreed (maybe too quickly?). Once again, this revives the discussion of how open source projects can be maintained in a healthy way, where corporations chip in instead of living off of the immense value a few highly motivated developers provide in their free time.

As a free software proponent, one option I see is to use GPL or AGPL for such projects. “Your work is freely available? Great, use my freely available stuff! Your work is closed? Great, can I interest you in this dual licensing deal?” And as @SwiftOnSecurity points out, have all the things ready to slap big companies with formal offers or support contracts, including a fax number and wire payment, so you seem legit and it’s easy for them to properly pay you. No Patreon, “give me 5$ for a coffee” bullshit — a proper business!

A common counter-argument is that copyleft-licensed projects have it much harder to become widely used. Possible, but then you’re at least not facing that much work. 😉

Shots

so long … Nicolai


PS: Don’t forget to subscribe or recommend! :)

CodeFX Weekly

Whatever caught my interest throughout the week: libraries or tools I am using, what I’ve written or read that might interest you, fascinating questions on StackOverflow, conferences visits, odd tweets, anything really that connects to Java, software development, or writing.

Nicolai Parlog

Written by

Developer (mostly Java), blogger (http://codefx.org/), author (http://tiny.cc/jms), trainer (http://courses.codefx.org & https://www.youtube.com/c/codefx)

CodeFX Weekly

Whatever caught my interest throughout the week: libraries or tools I am using, what I’ve written or read that might interest you, fascinating questions on StackOverflow, conferences visits, odd tweets, anything really that connects to Java, software development, or writing.

More From Medium

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade