Looking through the build errors on the adoptopenjdk build site for tipping-buster, the script is failing when it hits apt because it changes from stable to oldstable as Bullseye is now current stable, and the docker scripts don't know what to do with it. I don't know if this is a bug with the docker container, the script used, or if this is just a general build failure as I can't really see much else into it. I didn't want to open it up as a new issue in the wrong repo, but as there is no issue/discussion tab on the openjdk-ev3 repo I figured it might be safe to drop this here with some extra fluff.

Long story short, I'm interested in your build project, as you have the last remaining working autobuild going for armel in any form I can find on the internet, and the core of the TI ARM926EJ SoC in the EV3 is the same kind of core as is in the Marvell Kirkwood SoC which goes anywhere from 800MHz to 2GHz in many devices under the kirkwood flattened device tree. At the moment, the doozan forum is the place where these devices are continually being added to that tree, including dev boards, NAS appliances and even a Dell ARM-based asset management appliance (Kace M300) just recently.

I used build # 84 from a year ago, the current last working build, to complete a proof-of-concept to run a Minecraft 1.18.2 server on said hardware, a 2GHz Kirkwood with 2GB of RAM running Debian Bullseye this past month. it ran exactly as expected (pretty slow, but usable!!) without hiccups.

Currently, the version of OpenJDK 11 and 17 directly from Debian stable/testing/unstable for armel do not execute properly and no one is trying hard at fixing it. The only other build of OpenJDK available for softfloat armv5 is from Azul, but they are only building OpenJDK 11 for such. Everyone else has deemed softfloat not worth their time, and the companies that are supporting 32-bit ARM are doing it for hardfloat armv6l only for the 32-bit Raspberry Pi boards.

What you have is something special here that not only affects the EV3 brick in an educational manner, but it also functions on possibly thousands of appliances still out in the wild, with an untold number having been modified and running modern versions of Debian, where a functioning modern version of Java that isn't version 8 is needed, and not necessarily for a fool's errand of running a Minecraft server... but for any number of java-based daemons and applications such as Tomcat.

Hopefully the drive to build for these aging ARM devices isn't lost, as until someone else figures out the secret sauce to building a working OpenJDK instance for the compatible SoCs, this project is the lone light in the dark. Would also like to point out that as the Kirkwood SoC is code-compatible with the TI SoC and devices with 2GB of RAM are available for cheap new-in-box (the aformentioned Dell Kace M300 asset management appliance which goes anywhere from $25-35 on eBay), it is possible to utilize this as a much faster, resource-endowed native test platform, which may interest you.