Hacker News Reader

Comment by arianvanp | Hacker News Reader

We didn't have Bazel on ARM for NixOS because we can't bootstrap openJDK on ARM. There's no source code for a JVM that compiles on ARM afaik. Though in theory we could package binary blobs from oracle and bootstrap JDK and Bazel from there, it means now our trust path for your critical build tool has a random Oracle blob in its trust path there that is extremely hard to get rid off.

Build systems should be easy to build. Bazel is not by a far shot due to java being a mess in this area (ironic given it being advertised as a cross platform language).

These issues are not important for everyone perhaps. (Heck the entire Kubernetes ecosystem pulls random binaries from docker hub without any cryptographic signatures.) but it's still a shame; especially for a build system.

View on HN

Google builds stuff for themselves and then dumps it for extra reputation points on the dev community.

The part where this starts to suck is when their tools become pseudo-standards and everyone has to live with their decisions.

Right. Like the v8 javascript engine. If you want to build it, you need to download gigabytes of sources and install Googles internal build system tools first...

yes, and often lots of prebuilt build tools no one really knows how to build from source. It's a real mess open source.

This is actually called the "throw over the fence" open source development model.

Most Google projects are like this, including Android which is the main reason why vendors struggle with os updates.

AFAICT Android is a pain to upgrade because of custom closed-source drivers and lack of ABI stability in Linux, so you need to recompile a driver for a newer kernel.

Android is not a Google's internal product, unlike Bazel.

This. Treble is suppose be their ABI

Last week we had a major security vulnerability in Android just because Google can't user the same Linux kernel that everyone else are using.

There exist LTS kernel versions for a reason, you know.

They even maintain internal tools that are similar versions, but better. Google uses Borg internally, but they open sourced the cheap knock-off known as Kubernetes instead.

I'm biased because I work at Google on an open source project, but the complaint here seems to be:

1. A corporation spends significant resources developing a project.

2. Then they release to allow the public to use it at zero cost. Often they even invest in supporting that external use.

3. The project provides enough value to so many users (who chose it of their own volition) that it becomes nearly a standard.

And this is somehow a bad thing?

I think it's unfair to sketch it as such. Isn't it clear that the parent is unhappy with the side-effects, rather than the project itself?

The complaint is that the tech mega-corps are too big and should be broken up. Then they wouldn't distort markets (among other things) by dumping free products subsidized through ads on them, only to forget about said products two years later.

Regarding your specific interpretation:

1. The product was developed for internal use AFAIK, then released externally.

2. Google is getting something out of this: a PR boost, better engineer retention and the engineers feel good about themselves.

3. All these projects not only don't become standards, but they just add to the pile of things one has to learn because there are still too many people that are fawning over anything published by FAANG.

You could try cross-compiling OpenJDK from x86_64 to ARM. This is a lot easier in newer OpenJDK releases than it used to be.

Currently doing this for BSD using OpenJDK 11.

If needed, run with qemu userspace emulation.

> we can't bootstrap openJDK on ARM

Irrespective of Bazel, that's an lot of software than can't run on NixOS ARM, including build-related stuff:

* Elasticsearch, Cassandra

* Eclipse, IntelliJ, Netbeans

* Jenkins

* Java toolchain, Android toolchain

> (ironic given it being advertised as a cross platform language

Indeed that is one of Java's hallmark features. Servers, desktops, phones, toasters.

---

FWIW it's not unheard of to require compiling on one platform for another. This is how most of the embedded world works.

Is not the openjdk available for arm? What do you need from Oracle? https://adoptopenjdk.net/releases.html#aarch64_linux

This is aarch64 (that is 64-bit ARM), and NixOS seems more 32-bit arm looking at their wiki https://nixos.wiki/wiki/NixOS_on_ARM On the other hand, they do 64-bit too, so maybe there would be some way to do for one, then bootstrap the other?

Other idea, distributions like Debian, seems to build OpenJDK as well, so maybe that would be a way to get the initial package (through an existing distro) https://buildd.debian.org/status/logs.php?pkg=openjdk-11 - see the armel/armhf/arm64 architectures (arm64 equals aarch64).

We only support aarch64 officially. 32 bit ARM is only community-supported.

Aren't there 32-bit ARM binaries available here? https://bell-sw.com or here? https://adoptopenjdk.net/releases.html?variant=openjdk11&jvm...

Isn't there a way to get the Android toolchain to give you what you need? After all Dalvik is just Java warmed over and has a working VM, and there are plenty of ARM based Android phones.

That might get you bootstrapped to the point where you can use that to re-compile the community edition of Java.

You are conflating the runtime environment with the development framework. Afaik, you can't develop native Android apps on Android.

This was true for a long time, but we do actually have a bootstrapped openjdk for arm since a few months: https://github.com/NixOS/nixpkgs/pull/65247

You want to build java from source on arm ? Can’t you borrow what AdoptopenJdk Does

Can't you bootstrap older openJDK with (now discontinued) GCJ?

Reply on news.ycombinator.com