Long term plan to move to Java 17

We are trying hard to keep bnd useful in many different scenarios. This is the primary reason we try to keep the dependencies minimal. This includes versions. We are generally behind the Eclipse release train to give companies the time to update their tooling.

One of our largest dependencies is the VM. We’re still on Java 1.8, which is reaches its end of life date in a few months (March 2022).

If bnd was only used as a development tool then it would’ve been a no-brainer to upgrade to a later version. However, parts of bnd are used in embedded environments. Clearly the launcher is used in runtimes but we find bnd parts in the most unexpected places.

If you have 5 processor in the field, upgrading a VM version is not an easy task. It takes quite a bit of time to iron out all the bugs on the more exotic hardware. We therefore have been staying on Java 1.8 to reduce the problems we’re causing for our users.

We could’ve split the build into a 1.8 part and a 17 part but in my experiences that kind of needless variation is an exercise in masochism, software is already complex enough without self inflicted pain. We therefore decided to upgrade to Java 17 at the end of this year. Java 17 is, like Java 1.8, a long term support version (LTS).

Java 1.8 was a seminal version that removed one of my greatest problems with Java by introducing lambdas. However, to all parties comes an end, it has done a great job. However, it is time to move on. Although the new features in Java 17 are minimal, staying on older versions has a tendency to create its own nasty problems.

For most users this change will be invisible. However, if you’re in the embedded world it is recommended to start making preparations as soon as possible. It is less than a year and in our experience, it always takes much more time than expected.