FWIW, I spend a lot of my time writing low-level code, but more for desktop/server machines and less-so for mobile. > SoA requires unboxed arrays, otherwise it

FWIW, I spend a lot of my time writing low-level code, but more for desktop/server machines and less-so for mobile. > SoA requires unboxed arrays, otherwise it defeats the purpose. I may have been wrong about int[] being boxed Yeah, that's wrong. Primitive arrays aren't "boxed". An int[] is not an Integer[], and no boxing is performed unless you ask for it. SoA is fine in Java. > the fact that ints still auto-promote to Integer in certain circumstances It's pretty easy to avoid boxing if you don't want it. They are separate types after all. Even so, Android lint has an inspection for it, and Intellij (presumably Android Studio too?) has an inspection you can turn on to detect it [1]. If you're running afoul of autoboxing, it's probably mostly in collections-based code and you'll want something like fastutil [2]. > It's also hilarious that Value Objects are still in preview. Agreed, it's been a long time coming, but they've been doing a good job of releasing features that don't need deprecating five years later. > This is false. structs in C or C++ don't have a language-imposed overhead. They may have different sizes depending on the alignment requirements of the platform. Sorry, I misunderstood your comment. You were talking about different overheads on different platforms, and I read that as general overhead. (For example, if you run the exact same x86_64 binary on an Intel and AMD processor from the same generation, you can get drastically different results. Heck, you can get drastically different results within the same family from the same manufacturer for a half-dozen reasons). In any case, I wouldn't lose sleep over the varying size of object headers on different platforms. In the cases it matters, you should be avoiding them altogether. > Also hilarious. It's 2024. I don't know when Valhalla will land, but the Vector API is far smaller in scope. It's on its 8th incubator, and seems likely to land soon. You could give it a try. > Checking every single array access in a tight loop, for example, is stupid. This is a red herring in most situations. Your array accesses did get elided, you need to rewrite your code so it's easier for them to get elided, or the checks didn't have a performance impact. Also, you dev for mobile in Ada? > No, I am talking about Java. You must not be, because there are no exceptions used for control flow in code I write or review. > Oh, and how does Java do low-level systems programming without unsigned integer types, lol? It's annoying. You don't cast, you promote through a mask, e.g. val & 0xFF; That said, jOOU [3] looks interesting. > And you better hope you don't need more than the native size, because then you get fuck-boxed into Integer I don't understand this. You aren't using more than "native size" on any platform in any language without some sort of emulated Big* type. > Also, you don't even have a guarantee that a variable is allocated on the stack even when the dumbest compiler can tell it's bound by function scope. Implementations typically have both escape analysis and a nursery generation for this. This works well in a desktop/server environment. I can't speak to ART. Ultimately, Valhalla will solve this for constrained implementations. > I love LWJGL I'm knee-deep in GDX and LWJGL, right now, but again not in a mobile context. I used to hang out in the Java gaming forums with the folks who originated LWJGL (e.g. cas). > This is a criticism of the language, not the library I think your criticisms are mostly with ART. I agree there are a handful of language changes that would make things easier for ART. 1) https://www.jetbrains.com/help/inspectopedia/boxing.html#locating-this-inspection https://www.jetbrains.com/help/inspectopedia/boxing.html#loc... 2) https://github.com/vigna/fastutil https://github.com/vigna/fastutil 3) https://github.com/jOOQ/jOOU https://github.com/jOOQ/jOOU