Introduction
- What I want to accomplish: I want to move to Amazon Corretto 15 so I can use the new features in my work projects. These features feel long awaited; So much so, Kotlin and Lombok continue to gain popularity.
- How: I plan to convert an existing Java project from amazon‑corretto‑11 to amazon‑corretto‑15, and add code to the project which will leverage the new features just to see how our infrastructure handles them.
-
Caveats: This particular service is dockerized. So we would also need to update our docker image to use Java 15. I plan to run the project outside of docker just using
mvn
from a local shell.
Conversion process
Change the Maven compiler plugin version.
In the build section of the pom.xml
file:
<build>
<plugins>
. . .
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.1</version>
<configuration>
<release>15</release>
<compilerArgs>
<arg>--enable-preview</arg>
</compilerArgs>
</configuration>
</plugin>
. . .
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<forkCount>0</forkCount>
<argLine>--enable-preview</argLine>
</configuration>
</plugin>
. . .
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<configuration>
<argLine>--enable-preview</argLine>
</configuration>
</plugin>
</plugins>
<build>
I needed forkCount
in the surefire
plugin configuration because the parent pom declares something higher than 0
, SUREFIRE-1528.
This is a great reminder that some of the features in 15 are technically experimental still and require preview.
While I would be hesitant to use preview features in a production system, Amazon has faithfully iterated on corretto-11 through patches. Thus, as issues arise, there is iteration to fix those problems, and I believe that would also extend to preview features.
And I think it's safe to assume that corretto-15 will also have patches issued.
Installing Amazon Corretto 15
Or for the Linux users, you couldn't ask for a sweeter time: Linux package managed installation instructions
Updating my IDE
IntelliJ
Download the latest IntelliJ and you will have been all set to use Java 15 since version 2020.2!
Eclipse
Using the JDK
Just make sure when you're setting up your IDE, that you point to the correctto JDK installation!
Let's try out these Java 15 features
No more need for lombok here | Records
Here is a simple class in the existing project. Users in this domain are given a "baby step" between 0
and 7
.
With Lombok:
@lombok.Data
public class UserBabyStep {
public static final UserBabyStep NO_BABY_STEP = new UserBabyStep();
public static final int DEFAULT_BABY_STEP = 0;
public static final int MAX_BABY_STEP = 7;
private final int value;
public UserBabyStep() {
this.value = DEFAULT_BABY_STEP;
}
public UserBabyStep(final int value) {
if (value < 0 || value > MAX_BABY_STEP)
throw new IllegalArgumentException(
"The Baby Step of a user must be between 0 and 7 inclusively.");
this.value = value;
}
}
Hello records
!
public record UserBabyStep(int value) {
public static final UserBabyStep NO_BABY_STEP = new UserBabyStep();
public static final int DEFAULT_BABY_STEP = 0;
public static final int MAX_BABY_STEP = 7;
public UserBabyStep() {
this(DEFAULT_BABY_STEP);
}
public UserBabyStep(final int value) {
if (value < 0 || value > MAX_BABY_STEP)
throw new IllegalArgumentException(
"The Baby Step of a user must be between 0 and 7 inclusively.");
this.value = value;
}
}
Notes for record
Lombok will generate a more Java‑canonical getter method for fields: getValue()
. The getter method produced by the record
feature is: value()
.
This is more similar to how the Immutables library operates, and is a fancy way to get around when you may, or may not want isFlag
for boolean
getters. Especially if you are like me, and prefer leveraging the type system for wrapping primitives in a more domain‑driven class.
Another note is that record
‑declared classes cannot extend another class! Only implement interfaces.
Necessary usage of the canonical constructor
Finally, when using records, all constructors must call the canonical constructor. That is, the constructor with the same types, order, and number of arguments that are declared on the record itself.
Who's up for Checkers?
Instead of just looking for more things to change around in this existing project, I'm going to add irrelevant code simply for the sake of flexing the new features. And then, I want to see how it compiles and how the project plugins handle it.
Also, I isolated the checkers code if you'd like to take a closer look.
Sealed Interfaces
I'm going to mess around with this here, however, see the note at the end of the article concerning sealed interfaces.
A checker board tends to have two alternating colors tiling a 8 x 8 board.
Each space
/tile can have contents
; a red or black token.
To demonstrate the difference between individual tiles, there is a sealed interface called Space
which permits
a BlackSpace
and a RedSpace
. Each subclass then also implements the wither
method that allows a space to take new contents.
public enum Contents {
EMPTY, BLACK, RED;
}
public static sealed interface Space permits BlackSpace, RedSpace {
public Contents contents();
public int x();
public int y();
public Space withContents(final Contents state);
public default boolean isEmpty() {
return contents() == Contents.EMPTY;
}
public default boolean contains(final Contents state) {
return contents() == state;
}
public record BlackSpace(Contents contents, int x, int y) implements Space {
public BlackSpace(final int x, final int y) {
this(Contents.EMPTY, x, y);
}
@Override
public Space withContents(final Contents contents) {
return new BlackSpace(contents, x, y);
}
}
public record RedSpace(Contents contents, int x, int y) implements Space {
public RedSpace(final int x, final int y) {
this(Contents.EMPTY, x, y);
}
@Override
public Space withContents(final Contents contents) {
return new RedSpace(contents, x, y);
}
}
}
Now our CheckerBoard
can look a little something like this:
@SuppressWarnings("preview")
public class CheckerBoard {
private static int MAX = 8;
private final Space[][] spaces;
private CheckerBoard() {
spaces = new Space[MAX][MAX];
forEachSpace(
(i, j) -> spaces[i][j] =
((i + j) % 2 == 0)
? new BlackSpace(i, j)
: new RedSpace(i, j));
}
. . .
}
Note: that, if you are anything like me, you aren't a fan of warnings. So here's a way to suppress them for the preview features we'll be using.
Multi-line Strings
Java eliminates all leading whitespace between newlines!
Luckily, I already had a scenario where I would not need leading spaces in my string anyways:
class CheckerBoardTest {
@Test
void shouldPrintBoardAsExpected() {
final CheckerBoard subject = CheckerBoard.freshBoardWithTokens();
assertThat(subject.toString())
.isEqualTo("""
Ω · Ω · Ω · Ω ·
· Ω · Ω · Ω · Ω
Ω · Ω · Ω · Ω ·
· • · • · • · •
• · • · • · • ·
· ☺ · ☺ · ☺ · ☺
☺ · ☺ · ☺ · ☺ ·
· ☺ · ☺ · ☺ · ☺
""");
}
}
The google format spec basically has no idea what to do with this…
Pattern Matching in instanceof
(instanceof
casting)
This is a really handy trick that I wish was introduced much earlier.
It is also reminiscent of a feature of the AssertJ testing library.
The key use of this feature is to prevent a manual class cast of a variable after you are only in a block of code based on the type of a variable.
So instead of:
public void method(final Animal animal) {
if (animal instanceof Cat) {
((Cat) animal).meow();
}
}
We can do:
public void method(final Animal animal) {
if (animal instanceof Cat cat) {
cat.meow();
}
}
This method will set up a new checkboard and place the players' tokens in their starting positions. Since pieces should only be allowed to be played to the black spaces on the board, I can place pieces using the a wither
to keep each space
instance of my board immutable.
public static CheckerBoard freshBoardWithTokens() {
final CheckerBoard board = new CheckerBoard();
board.forTopThreeRowsOfSpaces(space -> {
if (space instanceof BlackSpace s) {
board.spaces[s.x()][s.y()] = s.withContents(BLACK);
}
});
board.forBottomThreeRowsOfSpaces(space -> {
if (space instanceof BlackSpace s) {
board.spaces[s.x()][s.y()] = s.withContents(RED);
}
});
return board;
}
To be fair, the cast here is not necessary. So if you can come up with a better use case, I'd be happy to hear about it in the comments!
Switch Expression
Our CheckerBoard
class has a convenient toString
method for a user friendly visual:
@Override
public String toString() {
return streamSpaces()
.map(space -> {
final String strSpace = (switch (space.contents()) {
case EMPTY:
yield space instanceof RedSpace? "·" : "•";
case BLACK:
yield "Ω";
case RED:
yield "☺";
});
return String.format(
"%s%s",
strSpace,
space.isRightEdge()
? "\n"
: " ");
})
.reduce(new StringBuilder(), StringBuilder::append, (l, r) -> l)
.toString();
}
That new yield
keyword at work! I can essentially iterate over each space
to yield a character.
More examples can be found here at this Baeldung article.
Issues
- google code formatter breaks. It looks like it breaks on records, multi-line strings, and the
yield
keyword that occurs in the switch expressions- To solve this, I think some motivated person could just start collaborating on Google GitHub repos for this. The spec repo The configuration repo
- the maven compiler (actually, the JVM) requires the
--enable-preview
flag to unlock the features. This is an obvious red flag for usage in production code. It is hard to assess the risk of using these features as well. In the past, many features of the JDK that shipped as previews in earlier versions of Java have actually functioned perfectly. Will that continue to be the case?
Wrap-up
One cannot simply assume that preview
Java feature will become integrated into the JDK long‑term.
The JavaDoc for the Record
class even contains a disclaimer:
This class is associated with records, a preview feature of the Java language. Programs can only use this class when preview features are enabled. Preview features may be removed in a future release, or upgraded to permanent features of the Java language.
In the case of records
, however, you can breathe easy, as it is officially integrated into Java 16.
As for the other features described in this article:
Feature | Java version introduced | Java version finalized |
---|---|---|
Pattern Matching in instanceof |
14 | 16 |
Records | 14 | 16 |
Multi-line Strings | 13 | 14 |
Switch Expressions | 12 | 14 |
Sealed interfaces | 15 | ? |
Sealed interfaces are still not officially being integrated. Even if they stick around, their syntax is subject to change. So that isn't a feature we were able to use here yet.
The other features that I listed as being integrated for version 16, have not changed syntactically since 15, (as far as I could tell). So with those, you're in the clear
Verdict
If you don't care about using the Google code formatter plugin for a while, and don't care about using sealed interfaces yet, you and your team can make the upgrade!
If for some reason you are still tempted to use the sealed interfaces anyways, I would strongly suggest not using them! It is not an officially integrated feature and could change or even go away.
A good example of this was the "Switch Expressions" feature. It was introduced in version 12 and overloaded the break
keyword. This was changed to yield
in version 13 to make more clear the intended behavior. Since it changed, it naturally needed to stay in preview in version 13, then finally was accepted in version 14. There's no telling what kind of iteration the sealed interfaces could still undergo.
Complete side-note | Speaking of features coming and going or staying
Sometimes, it is nice to declare a Function
in a Java Lambda, but you plan to return a specific object regardless of the input. In the past, I have used an underscore _
to define the variable of non-interest. Java 9 had discontinued this from being allowed.
Which I found interesting, considering that the introduction of _
as a variable name, had the apparent intention of being used in lambdas for unused arguments.
While in our code bases, we have now switched to using double underscores __
for this, we also use Vavr. So a nice alternative might be to use Function1.constant
.
Top comments (7)
Great article Alessandro! I like the part where you describe the simple Maven changes required to switch to Java 15 in preview mode 😀
@pmgysel I'm glad you could find it useful!
Good article on a few key changes in Java 15. However, from my experience, big projects have a tendency to fall behind in versions. They prefer stability rather than using the latest and greatest.
@pazvanti I concur! You do gain a little more freedom when iterating on very small projects/microservices, but unless there's a great advantage for switching, or great disadvantage for not switching, using what you have is a great idea.
Do you know sdk man?
It's a really helpful tool for managing several sdk's versions.
sdkman.io/
Thanks @viniciusvasti !
I had not heard of this until now.
Seems interesting. I'll check it out.
It's really usefull.
I have to change between Java 8, Java 11 and Java 15 constantly and all I need is run
sdk use java 8.0.275.open-adpt