Java UIO 2

OK, so it actually was cold in FL for a couple weeks and I did a power hack. I ported Java UIO to Java UIO 2.

Java UIO (HawtJNI)

This was the "Old School" high-performance approach. It relied on a custom C wrapper and JNI to bridge the gap.

• How it works: You have to write a C helper file, compile it into a shared library (.so) for on ARM architecture (armv7l, aarch64), and bundle it in your JAR.
• The Overhead: Every call from Java to C has a "JNI transition cost." To minimize this, you used moveJavaToNative to bulk-transfer buffers, which added complexity to the Java code.

Java UIO 2 (FFM / Project Panama)

• The "Modern" approach. It treats native memory and functions as first-class citizens in Java.
• I now cross compile on x86_64 for arm32 and arm64.
• How it works: Java uses Linker and SymbolLookup to find functions in u8g2 or libc directly. No custom C wrapper is strictly required unless you want to simplify complex macros.
• The Overhead: Transitions are heavily optimized by the JVM (often inlined). By using MemorySegment, you can point Java directly at the UIO hardware registers or the U8g2 tile buffer.
• The Armbian Advantage: It is "Write Once, Run Anywhere" for native code. As long as the system library (like libSDL2.so) exists on the Armbian filesystem, the same JAR will work on an Orange Pi 5, a Pine64, or even a Raspberry Pi without re-compiling C code.