Incorrect JNI installed for 64 bit raspberry pi that had been auto upgraded from 32 bit. getHardwareName() uses unsupported method to determine arch.

[billfor]

Describe the bug
As per raspberrypi/firmware#1795 , JNI architecture is incorrect for (at least) raspberry pis that were using a 32bit kernel and were upgraded at some point via apt update to a 64 bit kernel, but maintaining 32 bit userland because getHardwareName() in https://github.com/xerial/sqlite-jdbc/blob/master/src/main/java/org/sqlite/util/OSInfo.java is using arch -m to get the architecture which is not the correct way on a raspberry pi

User will get the following when trying to use the jni for sqlite-jdbc.

wrong ELF class: ELFCLASS64 (Possible cause: architecture word width 
mismatch)`*

file sqlite-3.40.0.0-052bfca4-00a0-416f-b5ac-b5e9d5232416-libsqlitejdbc.so (or whatever version) will show a 64 bit ELF which cannot run on a 32bit machine.

See raspberrypi/firmware#1795 for the correct way to determine architecture.
TLDR; use getconf LONG_BIT instead of uname -m

To Reproduce
Any use of the sqlite JNI on an upgraded rasbperry pi

Any use of the sqlite-jdbc jni where the following hold true:
root@rpi4:~#uname -m
aarch64
root@rpi4:~#getconf LONG_BIT
32
java -cp sqlite-jdbc-3.40.0.0.jar org.sqlite.util.OSInfo
Linux/aarch64 # <<<WRONG (at least for purposes of figuring out which JNI arch to run)

Expected behavior
Determine correct architecture for the library

Logs
See this for a practical example
https://community.openhab.org/t/openhab-installs-64-bit-jna-lib-on-32-bit-raspberry-pi-and-breaks-jdbc-sqlite/151051

Environment (please complete the following information):

• OS: rapberry pi
• CPU architecture: arm64 with 32 bit userland (and 32bit jvm)
• sqlite-jdbc version (latest. code is wrong in main)

[gotson]

This is nothing new, and has been reported multiple times here before. We added a way to override the detected architecture, see https://github.com/xerial/sqlite-jdbc/blob/master/USAGE.md#override-detected-architecture

IMHO this is a raspberry issue, not something the driver should fix.

[billfor]

Thanks. I am using that currently. Just trying to avoid defining system properties for everything that does not agree with the raspberrypi supported way of doing things.