# Notes for Java 17 Blog Post
###### tags: `blog`

## Intro

Since its the first blog post we should have a bit of background on SwissBorg using Scala as main language:

- In house knowledge of the language and ecosystem;
- Strongly typed language: really helpeful to refactor "rushed" solutions as we grow;
- Akka and the goodies around the CQRS architecture;
- Access to the mature Java ecosystem libraries;
___

- Java 17 release on Sep. 2021; (Showcase we are very fast)
- Java 17 new features since Java 11 (LTS to LTS version update) and why it is so cool.
- Why it matters to us?
- Want to keep up to date
- Being with the latest perf improvements (especially GC improvements. More info below)
- https://openjdk.java.net/projects/jdk/17/jeps-since-jdk-11
- SwissBorg is scala shop with some backend services running together in a event sourced arquitecture. Running on Java 11 so far.
- Scala is compatible with Java 17 (https://docs.scala-lang.org/overviews/jdk-compatibility/overview.html) and we are using Scala 2.13.7

## GC improvements

- At SwissBorg we used the default GC which means it will pick the actual GC depending on CPU and Memory usage. If small heap and low CPU: Parallel Collector, else Garbage-First (G1)

- Blog posts with some comparisons:
- https://kstefanj.github.io/2021/11/24/gc-progress-8-17.html
- https://tschatzl.github.io/2021/09/16/jdk17-g1-parallel-gc-changes.html

- On Java 17 LTS we get G1 to do preemptive garbage collections. (https://bugs.openjdk.java.net/ browse/JDK-8257774)
- Java 17 improved a lot the G1 GC perf (see blog posts above)
- Memory footprint will also be improved a lot on Java 18 (75% reduction). (2nd blog post, "Whats next" section for reference)

- To pick a GC one will pick something that favours latency or throughput according to needs. At SwissBorg we want something in between. We are ok with a GC that can perform well in both. That is why we ended up picking G1 GC.

(include screenshots, for instance the one Lomig shared on the slack thread: https://swissborg.slack.com/archives/C02FJ4P4C8J/p1640863799021700?thread_ts=1638538134.020100&cid=C02FJ4P4C8J)

## Which JDK to choose?

- We were using OpenJDK 11 (from AdoptOpenJDK) and we decided to remain with the same distro. In the meantime the organization rebranded (https://blog.adoptium.net/2021/03/eclipse-adoptium-announcement/) and now it goes by the name Adoptium and the distributed JDKs also got renamed to Temurin (which is an anagram for Runtime).

- When we started working on this (back in Nov/Dec.) the Adoptium organization decided to not proved JRE anymore, which meant that we had to build our own using `jlink` and choosing the the actual modules, so we had to learn a bit about `jdeps` and how to use it. However, currently Adoptium decided to go back on this decision, so they are providing official JRE (https://blog.adoptium.net/2021/12/eclipse-temurin-jres-are-back/). NOTE: @Julien we don't really need to expand on this. It might be cool to briefly mention it.

## Migration

- We just had one issue while updating to Java 17, which is related to strong encapsulation of JDK internals.
- `--illegal-access` flag was initialized with "permit" from Java 9 to Java 15;
- `--illegal-access` was then defaulted to "deny" on Java 16;
- This means that unsafe calls are treated as illegal and instead of warning out like before it now fails with: java.lang.reflect.InaccessibleObjectException

- At SwissBorg we use Kryo serialization to serialize the messages on our akka clusters. In some other places we also leverage Aeron (https://aeroncookbook.com/aeron/overview/). Both those projects use low level internal JDK apis. This was triggering Illegal access exceptions that we have to deal with.
This was immediatly spotted by our test battery and the fix was to allow access to those Java internal apis. To do that a extra parameter(s) needs to be given to the Java runitme. One random example is (what you need to pass will depend on what internals your app is accessing):
- `--add-opens java.base/sun.nio.ch=ALL-UNNAMED`

- More info on
- https://aeroncookbook.com/cookbook-content/aeron-jdk16/
- JEP 396: https://openjdk.java.net/jeps/396
- JEP 403: https://openjdk.java.net/jeps/403

- For rollout we slowly deployed our updated services running Java 17, while monitoring closely how they were behaving, in the span of two weeks, until all of them were deployed.

- As an extra point, on our internal libraries we are targeting ClassFile version of Java 11 (version: 55) and completly dropped support for Java 8 (version: 52). Java 8 is currently the default target in Scala compiler.

## Conclusion

The amount of work was not that much, or that difficult, compared to all the amazing improvements between the 2 LTS versions (11 vs 17).
Since we were using containers, swapping Java on our base images was quite easy and straightforward. Since it was that easy, we are probably going to experiment with updating to non LTS versions (ex: Java 18 75% reduction on memory footprint with G1 GC).

---> Remind that 11 is still fine, but 8 is at "end of life" stage and everyone should update. (Either put this here or in the intro).

Be like SwissBorg, update to Java 17.