Yes, I botched that one, agreed.
> 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].
Autoboxing is a contradiction of "It's pretty easy to avoid boxing". It's specifically egregious for any place where you need performance guarantees.
> 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.
Because you don't have unsigned integers (or arithmetic). So, for example, if you're playing with a 16-bit unsigned value, then you need a 32-bit signed integer to hold the 16 bits you care about (and you can kind of pretend you have 16-bit unsigned arithmetic.) But if you need a native-sized unsigned integer, you're out of luck.
> Implementations typically have both escape analysis and a nursery generation for this. This works well in a desktop/server environment.
Not on Google's VM the last time I tried. Shit went on the heap and the "concurrent" GC would then stall the entire application for ~1s every ~10s.
> 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).
I used to be on #LWJGL on Freenode, but it seems the guys moved to Discord or something.
By the way, we haven't talked about how horrible the JNI is, which requires you to wrap every C function so that you can pass around the JNIEnv handle and to manually marshal data structures to/from, like you're writing fucking Lua bindings or something. The right way to do FFI is the Haskell way, where you just call the function and get compiler support for auto-marshalling data structures (and, if you want, you can get your Haskell program to build and statically link the C library from source; no need to compile separately using another build tool and then dynamically load a shared lib.) Even C# does it better than Java. So in the use case where you have optimized C code and the rest of the application in Java, even the bridge itself is a pain in the ass to write.