When you're left behind

TIPS
1

bnd took the brave step to Java 17 and things seem to flow smoothly, we finally have the var keyword I always dreamed of!

For desktops and & server farms Java 17 is not in any way complicated, the amount of choice after in Java VMs is the abundance of riches nowadays. It is hard to remember the days where Java forced me to the Windows.

However, in the embedded world life is not that easy. Where the choice of 64 bit ARM or x86 VMs are plenty, it is already becoming very difficult to get 32 bit ARM support, let alone something like the MIPS processor. Even Azul, who I think has the best support in the industry, is showing strains in their 32 bit support. Java in general seems to drop 32 bit. Recently I experimented with the native code support in project Panama (that is now in Java 19) and it looks like 32 bit has become the retarded nephew the family prefers not to talk about.

The far majority of code in bnd is for developers, not runtime, therefore Java 17 is not an issue. However, there are a number of runtime libraries, most importantly the launcher. Since it is a very bad idea not to stay current with the development tools, how do you make sure that the launcher is not Java 17 for your poor abandoned target platform?

The trick to do this is to use the -runpath. When bnd makes an executable Jar out of your bndrun specification, it first analyzes the -runpath for the presence if a Jar with a Launcher Plugin. If it finds one, then the code in this launcher will setup the environment. Otherwise, it uses the default biz.aQute.launcher JAR that is part of every bnd(tools) delivery, it definitely contains a Launcher Plugin.

So if you want to keep on Java 1.8 for the launcher, just add a dependency to:

 biz.aQute.bnd:biz.aQute.launcher:6.4.0

Then in you bndrun file(s), add:

-runpath \ 
    biz.aQute.launcher;version='[6.4.0,7)'

You need to restrict the version because the bnd rule is the lowest version for compile and the highest version for runtime.

Since I’ve got several customers that are in this predicament, I created a separate branch for 6.4.0 and will keep the runtime libraries updated. This branch will not contain Gradle plugins nor maven plugins. It is purely intended for the runtime libraries.

2

Yes please, I would definitely appreciate a Bnd 6.4.x release of the library containing the @ServiceProvider and @ServiceConsumer annotations, because these need to be consumed by user code and I cannot force third parties to upgrade to Java 17 just so that I can sort their OSGi metadata out :smile_cat:.

And I would need to upgrade Bnd because the current @ServiceConsumer / @ServiceProvider annotations use Enum instead of String, and so are causing the FasterXML guys grief when their users cannot resolve these Enum classes in their annotated bytecode.