The State of meta-java

I would like to let everyone know that meta-java is mostly on life support at this point. The original founders and maintainers are long in-active and have not responded to emails in years. I am one of the only folks left that has push rights to the various repositories (Yocto Project, GitHub, Gitlab). After a decade or more of burning myself out trying to maintain multiple projects?where I am the last person standing, I have had to take a step back. The last decade has taken its toll literally on my health. I only work 40 hours a week, for my paying customers, as a consultant (https://www.konsulko.com). Anything more than that, such as this weekend, is my OWN TIME. My precious time away from friends and family and real life. Please respect that when you send patches.

Master First, Then Backport

My requirements for the current state of https://git.yoctoproject.org/meta-java are that any patches?MUST apply to "master" (meaning the development "walnascar" 5.2 release at this time, but we've been in this state since scarthgap at least and probably more like since kirkstone). If patches apply cleanly, including building and run-time testing, then I am willing to apply them. After patches are merged to "master", they are eligible to be backported to stable branches currently supported, such as kirkstone and scarthgap. I will likely completely skip styhead at this point and will branch for the walnascar release, if we achieve a functional layer. Otherwise, the major focus would be on "master" and the LTS releases (currently kirkstone and scarthgap). Non-LTS releases will not be a priority.

Continous Integration

I have a branch with continuous integration somewhat working, running on my own hardware on my own time at my own cost for the electricity and maintenance. If anyone is willing to provide long-term funds (think in multiple years or a decade) for an organization-wide Gitlab runner (or Github Actions runner), it would be much appreciated. My current staging branch is?https://gitlab.com/moto-timo/meta-java/-/tree/gitlab-ci?ref_type=heads.

I happened to have both the itch to scratch (desiring continuous integration and responding to recent patch submissions) and the energy and motivation to work on it over the weekend. At this point I am approaching 16 hours of my free time in the last two days that you should respect and value at a reasonable hourly rate. It has been about 9 months since I was last willing to do that. I cannot promise any energy or effort in the next 9 months.

If you look at the recent jobs, you will see that for all platforms (qemuarm, qemuarm64, qemux86-64) the jobs had to be canceled because openjdk-8 (target) is either timing out or causing a segfault. For qemuarm (32-bit), there is a problem with fuzzing for a patch for hotspot which I am currently at a loss to fix. My attempt to refresh the patches broke ALL builds, not just qemuarm. There is also a significant problem with fetching from hg.openjdk.net.

Many Upgrades Needed

We need to upgrade many components in the layer. The old approach of fetching multiple tarballs for jdk, hotspot, corba etc. from the mercurial openjdk repository is VERY brittle. Most of the time I am unable to fetch from that source. Modern openjdk is using other sites for providing sources and is bundling them together in one tarball (usually .xz compressed), instead of the madness of tracking several separate changesets. Many other components have newer versions, but we need to refactor the code base and move forward. Then we also have to decide what gets backported and how far back. We've been essentially at a stand-still since at least kirkstone timeframe.

Moving Forward, Always

I do not see much future in supporting openjdk-7, so it is a strong candidate for being dropped.

We need to support newer jdk releases (11, 17, 21+). As I mentioned in my Yocto mini-summit talk (https://www.youtube.com/watch?v=rwkAVxFTVw8), the requirements for building from source are that an N-1 release builds the N release. If you do the math, it is absolute insanity to build ecj -> intermediate -> icedtea-7 -> openjdk-8 -> 9 -> 11 -> ... -> 17 -> 21. HARD NO. We need to use a binary native approach (similar to go in oe-core) to bootstrap a build. I have some work-in-progress staged, but this requires at least a week (more likely two) full time to complete. I WILL NOT do that on my own time. See my statements about literal health impact above.

Until I am able to completely build at least openjdk-8-test-image and openjre-8-test-image for qemuarm, qemuarm64 and qemux86-64 (and really we should be also building for musl), I cannot CONFIDENTLY merge most patches. When openjdk-8 and openjre-8 are stalling/segfaulting on my Debian 12 build machine (even with kas-container 4.6), there is no path forward.

Support What You Depend Upon

If you depend upon meta-java for your product, please consider joining with others to fund my time (https://www.konsulko.com) so that I can focus on the layer during working hours. Alternatively, set up your own Gitlab CI runner with my gitlab-ci branch and send patches to fix the segfault/stall in openjdk-8/openjre-8. There are also some lingering issues with building icedtea7-native on Debian 12/Ubuntu 22.04+, but at least for now that has succeeded with a kas 4.6 containerized build.

If you depend on meta-java, please contribute in a constructive way to the community. But until a COMPLETE test image can be built on the current "master" (poky "walnascar" 5.2 in development), there will not be much merging happening. If you cannot show PROOF?of a COMPLETE openjdk-8-test-image and openjre-8-test-image for a minimum of qemuarm, qemuarm64 and qemux86-64, then I will reserve the right to ignore your patches. Be prepared to then answer problems with musl builds, as there are a separate set of patches and problems there.

Future Dreams

In the future, I would like to enable testimage and run-time testing of images, and possibly even real on-target hardware testing (such as raspberrypi?or beagleplay?targets). We can see an approach to reporting such results in the meta-arm layer that is very promising. I have the beginnings of some labgrid testing infrastructure that could run those tests on real hardware and publicly share those results. This takes time, money, energy and motivation.

You only get out of Open Source what you support in it.

We can do this.

Cheers,

Tim