4 ms·

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 w

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.

jacquesm 7y ago
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.
- fooker 7y ago
  You are conflating the runtime environment with the development framework. Afaik, you can't develop native Android apps on Android.
blub 7y ago
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.
- jakobegger 7y ago
  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...
  - neop1x 7y ago
    yes, and often lots of prebuilt build tools no one really knows how to build from source. It's a real mess open source.
- panpanna 7y ago
  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.
  - nine_k 7y ago
    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.
    - Grazester 7y ago
      This. Treble is suppose be their ABI
    - panpanna 7y ago
      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.
- journalctl 7y ago
  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.
- munificent 7y ago
  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?
  - cerberusss 7y ago
    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?
  - blub 7y ago
    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.
pgrulich 7y ago
Is not the openjdk available for arm? What do you need from Oracle? https://adoptopenjdk.net/releases.html#aarch64_linux https://adoptopenjdk.net/releases.html#aarch64_linux
- imrehg 7y ago
  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 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 https://buildd.debian.org/status/logs.php?pkg=openjdk-11 - see the armel/armhf/arm64 architectures (arm64 equals aarch64).
  - arianvanp 7y ago
    We only support aarch64 officially. 32 bit ARM is only community-supported.
  - frankgrimes97 7y ago
    Aren't there 32-bit ARM binaries available here? https://bell-sw.com https://bell-sw.com or here? https://adoptopenjdk.net/releases.html?variant=openjdk11&jvmVariant=hotspot#arm32_linux https://adoptopenjdk.net/releases.html?variant=openjdk11&jvm...
zaphirplane 7y ago
You want to build java from source on arm ? Can’t you borrow what AdoptopenJdk Does
rjsw 7y ago
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.
- namibj 7y ago
  If needed, run with qemu userspace emulation.
paulddraper 7y ago
> 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.
Vogtinator 7y ago
Can't you bootstrap older openJDK with (now discontinued) GCJ?
timokau 7y ago
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 https://github.com/NixOS/nixpkgs/pull/65247

jacquesm 7y ago

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.

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

blub 7y ago

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.

jakobegger 7y ago
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...
- neop1x 7y ago
  yes, and often lots of prebuilt build tools no one really knows how to build from source. It's a real mess open source.
panpanna 7y ago
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.
- nine_k 7y ago
  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.
  - Grazester 7y ago
    This. Treble is suppose be their ABI
  - panpanna 7y ago
    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.
journalctl 7y ago
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.
munificent 7y ago
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?
- cerberusss 7y ago
  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?
- blub 7y ago
  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.

pgrulich 7y ago

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

imrehg 7y ago
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 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 https://buildd.debian.org/status/logs.php?pkg=openjdk-11 - see the armel/armhf/arm64 architectures (arm64 equals aarch64).
- arianvanp 7y ago
  We only support aarch64 officially. 32 bit ARM is only community-supported.
- frankgrimes97 7y ago
  Aren't there 32-bit ARM binaries available here? https://bell-sw.com https://bell-sw.com or here? https://adoptopenjdk.net/releases.html?variant=openjdk11&jvmVariant=hotspot#arm32_linux https://adoptopenjdk.net/releases.html?variant=openjdk11&jvm...

zaphirplane 7y ago

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

rjsw 7y ago

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.

namibj 7y ago
If needed, run with qemu userspace emulation.

paulddraper 7y ago

> 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.

Vogtinator 7y ago

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

timokau 7y ago

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 https://github.com/NixOS/nixpkgs/pull/65247