Bump the minimum Java version?

[FDelporte]

At this moment, Pi4J V2 is built with Java 11 as the target, see https://github.com/Pi4J/pi4j-v2/blob/develop/pom.xml#L252

        <!-- JAVA COMPILER VERSIONS -->
        <java.version>11</java.version>
        <maven.compiler.source>${java.version}</maven.compiler.source>
        <maven.compiler.target>${java.version}</maven.compiler.target>

This means we miss out on many newer Java language and runtime improvements. Future versions will also make it easier to call C code to interact with the GPIOs, like JEP 454: Foreign Function & Memory API.

Do you agree we should move forward and bump Pi4J to a higher Java version? If so, which one?

[johanvos]

Is following the Tip & Tail approach (https://openjdk.org/jeps/14) an option here? You can branch out 11 here, and only add things to it when there are critical (security) issues, while using a later JDK version (21/23) on the tip?

[FDelporte]

Thanks for the tip! Will take a look at this...

[eitch]

Basically i have no issue back porting fixes. Lately most changes were new features and thus wouldn't have been backported anyhow. But the idea is definitely valid and i would always backport them, if needed.

[taartspi]

I selected the LTS. As the code base is used in various projects/products i think we owe the community the level with the most stable support

[FDelporte]

Last weeks I have been experimenting a bit with Java on 32-bit Raspberry Pi (for older boards). As far as I know, only Java 8 and 11 are available. So if we bump to a higher version, we will exclude these boards from newer Pi4J features later.

This is not a deal-breaker as we still will have the latest stable 2.X.Y release for those use-cases. But in that case, we will need to clearly document this.

[taartspi]

I saw u made v3.0 for the java 21. That works well for the users. We need to also add some doc detail on how we implement fixes needed in both versions.

[FDelporte]

It's only a first step, as an experiment to see if build etc. works... If we proceed like this, fixes will only applied in new V3 versions. Except for critical/security issues, these would be "backported".

[FDelporte]

Closing this discussion. As of version 3.0.0 Pi4J will be based on Java 21.

[laluha]

Keep java 11. ARMv6 devices has no java version higher than 11. This will abandon older pi's.

[FDelporte]

Agree and disagree ;-)
We have the stable version 2.8.0 which is Java 11 and is "feature complete" for all boards we know of today.
New development is mainly focused on newer boards like the new provider for Raspberry Pi 5 that was added recently.
Of course, critical bugs can still be backported to the 2-branch via the Tip & Tail approach described above by @johanvos

[FDelporte]

Java 21 branch is merged! See https://www.pi4j.com/blog/2025/20250211-welcome-java-21/

[hackerjimbo]

I've been following this for some time now. I agree with the idea of keep 2.8.0 on Java 11 and stable, with only bug (including security) fixes being applied (and maybe new boards. This also means that the v6 Pi boards out there (Pi 1s (there are many legacy), and Pi Zeros (important because they are still available and cheap)) can continue to work.

There is however an issue. The docker-based (not podman?) build of the libgpiod because although it's compiled for the right architecture, it's linked against debian's v7 libraries and throws an illegal instruction error on Pi Zeros and 1s.

I think the best solution is to build that library on a 32-bit version of Raspberry Pi OS. That's solve the problem. I even has a spare Pi 4 I can use to do this.

Does anyone have any thoughts on the subject? Perhaps an alternative is to not use libgpiod on a Pi 1…

[hackerjimbo]

I've been on 2.x for some time now. It worked with 2.6 but it's the later versions that break (I'm not sure exactly when). What changed in the build process?

Is there a maven (or make even!) task that can be run to build those libraries on the local machine? My ``patch'' solution describe above could so that, I just need to be able to compile the native libraries on my own machine rather than inside a docker container.

[hackerjimbo]

OK, I managed to get the patch process to work and now 2.8.0 works on a Pi 1!

Do I get bonus points for finding a bug in libraries/pi4j-library-pigpio/src/main/java/com/pi4j/library/pigpio/impl/PiGpioNativeImpl.java? I'll post the fix tomorrow, basically it's a bug on line 1472 where the third argument to copyOfRange should be offset + length because it's not the length, it's the last element + 1.

[FDelporte]

You get all the bonus points you want @hackerjimbo 😉

[FDelporte]

Can you please provide the hack instructions to add to the website?

[hackerjimbo]

Sure! But to summarise, you just need to compile on a 32-bit Raspberry Pi OS system — it doesn't have to be a Pi 1. By compile I mean just the few (4?) .so files in the pi4j-library.*.jar files. I'll write it up tomorrow.

[hackerjimbo]

OK, this took a long time coming and it's an early draft, but comments please! This only covered creating the .so files.

Building Pi4J 2.8.0 for a 32-bit Pi with ARM v6

The problem

The current build system uses a 32-bit Debian cross-compile. This almost works fine. The compile phase correctly builds for the v6 architecture; however, the link phase to build the .so files uses Debian libraries which are compiled for the v7 architecture.

The end result is that running pi4j on a v6 Pi results in an illegal instruction and the program aborting.

This matters because of the legacy Pi 1s out there and also because some cheap and/or small systems will want to use Pi Zeros. It seems unfair to leave them out.

Fixing it:

For this you will need a reasonably powerful 32-bit Pi. I use an 8GB Pi 4 running the 32-bit version of Raspberry Pi OS. This is more than adequate for the task.

Step 1: Build Pi4J. For this I downloaded the .tar.gz of 2.8.0, went into the top directory and ran mvn package.

Happy days, it builds.

Now we need to rebuild the .so files.

Let's start with libpi4j-linuxfs.so

jim@pi32:~/Build/pi4j-2.8.0 $ cd libraries/pi4j-library-linuxfs/src/main/native
jim@pi32:~/Build/pi4jNow we're done on the building. It's time to patch.

I started with:

jim@pi32:~/Build/pi4j-2.8.0 $ mkdir ~/repack
jim@pi32:~/Build/pi4j-2.8.0 $ cp ~/Build/pi4j-2.8.0/pi4j-distribution/target/pi4j-2.8.0.tar.gz ~/repack
jim@pi32:~/Build/pi4j-2.8.0 $ cd ~/repack
jim@pi32:~/repack $ tar xfx pi4j-2.8.0.tar.gz 
jim@pi32:~/repack $ 
-2.8.0/libraries/pi4j-library-linuxfs/src/main/native $ make
[COMPILE] com_pi4j_library_linuxfs_internal_LinuxFS.c
[LINK with DYNAMICALLY linked libraries]
jim@pi32:~/Build/pi4j-2.8.0/libraries/pi4j-library-linuxfs/src/main/native $ ls -ltr
total 48
-rw-r--r-- 1 jim jim 2254 Jan 28 12:24 Makefile
-rw-r--r-- 1 jim jim 2347 Jan 28 12:24 com_pi4j_library_linuxfs_internal_LinuxFS.h
-rw-r--r-- 1 jim jim 4566 Jan 28 12:24 com_pi4j_library_linuxfs_internal_LinuxFS.c
-rwxr-xr-x 1 jim jim 5168 Jan 28 12:24 build.sh
-rwxr-xr-x 1 jim jim 2612 Jan 28 12:24 build-prerequisites.sh
-rwxr-xr-x 1 jim jim 2500 Jan 28 12:24 build-liblinuxfs.sh
-rwxr-xr-x 1 jim jim 2344 Jan 28 12:24 build-docker.sh
-rw-r--r-- 1 jim jim 2300 Mar 18 17:22 com_pi4j_library_linuxfs_internal_LinuxFS.o
-rwxr-xr-x 1 jim jim 7856 Mar 18 17:22 libpi4j-linuxfs.so
jim@pi32:~/Build/pi4j-2.8.0/libraries/pi4j-library-linuxfs/src/main/native $

Here we've built libpi4j-linuxfs.so. Now copy it somewhere safe as we'll be needing it later:

jim@pi32:~/Build/pi4j-2.8.0/libraries/pi4j-library-linuxfs/src/main/native $ mkdir ~/patches
jim@pi32:~/Build/pi4j-2.8.0/libraries/pi4j-library-linuxfs/src/main/native $ cp -a libpi4j-linuxfs.so ~/patches
jim@pi32:~/Build/pi4j-2.8.0/libraries/pi4j-library-linuxfs/src/main/native $ 

Next up is libpi4j-pigpio.so, it's practically identical:

jim@pi32:~/Build/pi4j-2.8.0/libraries/pi4j-library-linuxfs/src/main/native $ cd ../../../../pi4j-library-pigpio/src/main/native
jim@pi32:~/Build/pi4j-2.8.0/libraries/pi4j-library-pigpio/src/main/native $ make
[COMPILE] com_pi4j_library_pigpio_internal_PIGPIO.c
[LINK with DYNAMICALLY linked libraries]
jim@pi32:~/Build/pi4j-2.8.0/libraries/pi4j-library-pigpio/src/main/native $ cp -a libpi4j-pigpio.so ~/patches/

Now we come to the slightly harder . The first part is the same as the above:

jim@pi32:~/Build/pi4j-2.8.0/libraries/pi4j-library-pigpio/src/main/native $ cd ../../../../pi4j-library-gpiod/src/main/native/
jim@pi32:~/Build/pi4j-2.8.0/libraries/pi4j-library-gpiod/src/main/native $ make
[COMPILE] com_pi4j_library_gpiod_internal_GpioD.c
[LINK with DYNAMICALLY linked libraries]
jim@pi32:~/Build/pi4j-2.8.0/libraries/pi4j-library-gpiod/src/main/native $ cp -a libpi4j-gpiod.so ~/patches
jim@pi32:~/Build/pi4j-2.8.0/libraries/pi4j-library-gpiod/src/main/native $ 

The hard part is building the gpiod code itself.

jim@pi32:~/Build/pi4j-2.8.0/libraries/pi4j-library-gpiod/src/main/native $ export HOST=armhf   
jim@pi32:~/Build/pi4j-2.8.0/libraries/pi4j-library-gpiod/src/main/native $ ./build-libgpiod.sh 

This will attempt to build libgpiod. It will fail! There may also be a lot of dependencies you need to install here, but I didn't log them. Sorry! Basically for every command that's missing you need to install it. This will depend a lot on what is on your machine already.

What it does create is enough to try the build. Let's configure it:

jim@pi32:~/Build/pi4j-2.8.0/libraries/pi4j-library-gpiod/src/main/native $ cd gpiod
jim@pi32:~/Build/pi4j-2.8.0/libraries/pi4j-library-gpiod/src/main/native/gpiod $ ./configure

This produces lots of output. More importantly, it write a Makefile! Now run make. This leaves us lib/.libs/libgpiod.so.2.2.3, copy that to your patches area as libgpiod.so.

[FDelporte]

Thanks @hackerjimbo !

Two followup questions:

• what must users do with file to make their application run?
• maybe it would be an idea to create a merge request with /32bit/2.8.0/your-files to https://github.com/pi4J/pi4j-os?