Rawdrawandroid – Build Android apps without any Java, in C and Make
github.com
github.com
I've stopped counting how many times I came back to an Android project after only a few months, only to have Android Studio force me to update Gradle and dependencies and whatnot, and break everything.
* Of course one could blame me for not learning the ins and outs of the build system!
This. And people are surprised that many just wrap websites as apps on Android.
Try and do it. if you run into a deal breaking issue with PWA features, then wrap it in a minimalist app shell.
Best case: everything works on Android and iOS and it's also a website.
Worst case: you will end up doing some platform specific code and dealing with the app stores like you were going to do anyway.
Average Case: everything will work on android and some things will be broken on iOS.
Even now if I need a "native" app I'm looking very seriously at React Native first before rolling two totally separate apps in different languages.
Unfortunately you can't just ship a PWA with no wrapper. You have to build a special wrapper app that hosts the PWA and you have to use Android Studio and Gradle and all that crap.
Updating the wrapper is surely still easier than a whole app, but it's nontrivial and it's frustrating to still have to deal with the platform BS for a pure web app that uses no platform APIs at all. More work than I wanted to deal with for a hobby project, anyway.
You can… but it won’t be in the Play Store. Disqualifying for many, but not all.
I don't think so.
Proguard is fun too, with how it'll carve out or break chunks of functional code if you don't spell out precisely what shouldn't get deleted/obfuscated.
VSCode isn't bad but disliking Android Studio just feels like you started with it and didn't want to learn a different tool.
All development work takes place in VS code, including the incredibly incredibly convenient and performant hot code reload, as well as the final step of "flutter build ios"/"flutter build aab"
It is an experience with very few pain points* and I find it to be very enjoyable.
*except for the random Cocoa Pods error every few months which can be solved by random helpless googling and then deleting the podfile.lock
It's a native Android app (Kotlin) which isn't developed using Android Studio. Gradle only.
Unfortunately this doesn't actually protect you from that since you still have to deal with that for both the actual "make an APK" step as well as the Java bindings for critical features.
This used to be 5-6 years back. These days it is very stable.
I actually _like_ Java, so it's not that I hate Android, but frankly, I have no idea what it is even doing downloading and generating gigabytes of crap with inscrutable huge log files. Most of my applications' Java/GUI parts are no more complex than a hello world -- many times I find it easier to just rewrite them from scratch than even try "upgrading" them using Android Studio.
The Android tooling is basically a textbook definition of oversized enterprisey software. I really wish there was just a frigging (resource) compiler, linker and maybe packer that I could invoke from the command line in simple steps.
Yeah, I feel the same. There are CLI approaches that I have encapsulated into Makefile ( https://ashishb.net/all/use-makefile-for-android) and GitHub Actions (https://github.com/ashishb/gabo/blob/master/src/gabo/interna...) but they do require time to set up.
As a Gradle veteran, I've written in detail about this previously:
https://news.ycombinator.com/item?id=38875936
TL;DR: Gradle is too powerful (which is fun and seems valuable at first!) with too many footguns. Combine this with the mandatory update migrations and you're literally signing up for future pain compared to using a lower change-rate build tool like Maven. Do you really need to run arbitrary commands to build your app? If so, take a deep gaze in the mirror and reflect on what you're doing with your life.
Gradle is not too powerful, it builds a build graph based on the .gradle file, and the building itself happens imperatively — but the actual execution is static, based on that fixed build graph. This configuration is cached and subsequent executions will all refer to this static graph to know what requires rebuilding.
This is the minimum required complexity/generality for a build system that is not “hardcoded” for a given task (e.g. to a degree maven, but cargo, go’s build tool etc all can only compile their respective languages on their own. “Plugins” can let them do more, but at that point plugins have to re-develop all the functionality of a build system - caching and parallelization), and as I mentioned there really are only a handful of tools capable of that.
As for valid criticisms of gradle - it’s API historically experiencing constant breakages, used to be dependent on JDK version (and lagged behind for a long time due to Groovy), which is more or less fixed now with toolchains, and the model not being clear enough for people not wanting to dive deep. E.g. I can count on a single hand how many people knows that doFirst/doLast should be used for the actual task itself, anything else will happen at the config build time which is not what you want.
Had it not been for Android replacing Ant with Gradle, and most folks wouldn't even remember Gradle.
In other cases, updating Gradle won't give any problem. You can build the APK fine. Debugging the build system is annoying :D
Each time I have to touch it, it results in problems... Oh, you updated JDK? Gradle won't work. There is new Gradle? Tough luck it will break your build..
And with Maven it can update and the build keeps working just fine.
To that end I mostly ignore prompt "update gradle!" in Android Studio to avoid any issues...
Maven is virtually infinite extensibility via plugins. The difference is that gradle is easier to "hack" and put the build logic in your configuration...
> E.g. maven can often “lose” that something requires a rebuild, and only clean build will produce the correct artifacts.
This is not build shortcoming but rather detection what requires rebuild and what not but in the worst case scenario it rebuilds everything…
> Gradle can always keeps track of tasks correctly.
LOL, from my experience that is not true.
Also, if you have multiple projects using different gradle version this results in multiple daemons running in the background. Besides gradle builds as as slow as maven...
Losing the only task of a build tool, caching and parallelization.
No, the problem is that maven doesn’t rebuild everything. It is actually quite common in code bases that I had to run clean build instead of build to actually recompile everything that changed. I guess maven just doesn’t have an accurate build graph?
> LOL, from my experience that is not true
In what way is it not true?
Also, gradle is demonstrably faster, especially on projects that can be parallelized. Obviously a hello world will be dominated by javac and build tool startup speed so it’s not relevant.
And multiple daemons — you can disable them, and they will go away if unused.
You are aware that Maven does offer paralle build, right?
> I guess maven just doesn’t have an accurate build graph?
You guess wrong? then
>> LOL, from my experience that is not true
> In what way is it not true?
Consistency of gradle build. You yourself stated just a paragraph above that sometimes you have to run "clean" xD
> Also, gradle is demonstrably faster, especially on projects that can be parallelized. Obviously a hello world will be dominated by javac and build tool startup speed so it’s not relevant.
Again, learn the tool. Maven does offer parallel builds and is comparably fast…
> And multiple daemons — you can disable them, and they will go away if unused.
"but you are turning off the only feature of a build!!!"
Also - I had a setup open with gradle/kotlin-multiplatform project (shell with "gradlew" and Android Studio) and magically it fails to build with "Unresolved reference: kotlinx" even though I haven't done anything to the project and no ammount of running "gradlew clean" solves it... what a lovely tool....
That was in reference to maven..
Also, feel free to show me any benchmark showing maven being as fast as gradle. https://gradle.org/gradle-vs-maven-performance/
I tried and * commons took more than 2,5 minutes to build (they show 70s?) * tried their tests (medium project, https://github.com/gradle/performance-comparisons/tree/maste...) and maven compiled it in 4s and usual "clean install" took 14s but they don't enable paralel test run); then I tried running "gradle build" and... got an error:
``` FAILURE: Build failed with an exception.
* Where: Build file '/Users/wojtek/dev/tmps/performance-comparisons/single-medium-project/build.gradle' line: 16
* What went wrong: A problem occurred evaluating root project 'single-medium-project'. > Could not find method compile() for arguments [commons-lang:commons-lang:2.5] on object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler. ```
It's so nice that even gradle team themselves can keep up with their crap xD but of course it's probably due to convoluted setup... again - with maven you just clone and build and be done with it, with gradle you have to "stand on your head" to figure how to make any progress... I updated the build.gradle (according to https://docs.gradle.org/current/userguide/declaring_dependen...) and `gradle build` finished in 19s...
So your beloved gradle is 25% slower and can't even be compatible with itself...
I took a look at "large-multimodule" to have something more challenging but: they setup each project individually and for some convoluted reason configure maven compiler with `<source>1.5</source>` (and JDK21 complains) and same goes for gradle modules with broken `dependencies`. I adjusted it but then it turned out that the sources can't even compile (due to wrong arguments in tests) ffs...
Almost no other build tool has had so many conference talks regarding performance issues, and dealing with its gotchas as Gradle.
I am absolutely not bothered by XML and alia (btw, there are maven frontends in json/yaml, etc for those who are), and throwing out valid criticism over some straw man is not really productive.
Context: I worked on a Spring app many years ago and am picking Java back up.
But I have run into issues with multi-module projects and the like, and it can be very frustrating to realize that you are trying out some corrupt version. Nonetheless, maven is also a cool and stable tool, but you are better off adding a clean step from time to time.
The structure is (using [dirname] notation for directories)
[Repo Root]
...git and github files, READMEs...
[Flappy Bird]
... project files, keystore, build.bat ...
[App]
[build]
... I'm ok with tools making a mess here as long as outputs is tidy ...
[outputs/apk]
..the actual .apk
[src]
[main] this seems a little off, main contains libs and resources
Android_Manifest.xml Yep ok, I'll rant about that later, that's its own thing
[assets] all good
[res] Wait what? that's like a synonym for assets, (but for a different layer)
[libs] Hang on, these are .so files. built libs should be in the build dir
[jni] This looks like what src or src/main should have had inside it
I'd Shuffle it around to make [Flappy Bird] contain [main] and [build]. move [libs] to [build/libs] rename [jni] to [src].
If you had an architecture like that then the one-true-build-system should be a command line tool that you can point at [main] and it does what [Flappy bird]/build.bat does only with auto detection of the installed tools, optional config file overrides, optional commandline overrides.
AndroidManifest is another issue entirely I'd like something that invisibly converted something sane to XML and I'd never see it again, but I'll grin and bear it. A decent validator and maybe I'd like a standalone AndroidManifest editor that knew what everything did and could provide appropriate boilerplate.
After typing this up (mostly as organizing my thoughts), I actually think you could have a relatively painless way to make Android Apps.
Ideally tools should support, not dictate. For instance, if you were building a simple source only app with no assets, a good tool should be able to be pointed at, say, a main.c file in the directory and be able to use the contents of the directory containing main.c for other required files and work with no special extra configuration. Supporting a structure to keep things clean is great, Imposing one(whether you use the features it offers or not) is poor.
I might take a look at the NDK and see if it can be circumvented.
Wait till you want to build anything reasonable.
All libraries for Android are in Java and/or Kotlin. If you have to write all of them in C then best of luck doing anything meaningful.
What kind of libraries? Anything related to SSO. Anything related to Material design. Anything related to any ancillary services that you want to integrate with e.g. Google services.
The few times there wasn't a plugin to do what I needed, I've managed to roll a custom one pretty easily.
When Vite breaks you're completely screwed though. Find a different way to do it or wait until a patch comes out. Vite internals are nigh impossible to fix on your own.
Dissatisfied with the state of the vendor SDK for CH32V003 microcontrollers (ultra-cheap RISC-V MCUs), he created his own [1], which is a pleasure to use. He also has a header-only RISC-V emulator that runs Linux (and Doom!) [2], and hacked an ESP32 to emit valid LORA frames with clever use of aliasing [3].
[1] https://github.com/cnlohr/ch32v003fun
the ndk is meant for writing little bits of c to speed things up in a classic java android application.
this is a pretty cool hack that allows for opengl apps to be written in straight c that run full screen and have limited access to things like keyboards, adc inputs or usb.
it does not include a reimplementation of the android frameworks in c and the ndk provides limited access for ndk code to interact with them.
the main use case seems to be supporting a program for live audio reactive visuals based on extraction of chroma.
And it is! Hah.
I'm doing a desktop app meant to be as cross compatible as possible and the only reasonable way to do it (without sending yourself into build config hell) is with opengl.
It's not even a hack. Android NDK added that way back in like gingerbread, it's just a NativeActivity. https://developer.android.com/ndk/samples/sample_na
This is just a small framework on top of that. It's not doing anything "new"
Looking briefly at the makefile, I think they might have avoided Gradle, though it calls other tools written in Java.
I'd love to see a way to build a Flutter app without Gradle.
unzip somewhere, set path variable
> yes | sdkmanager --licenses && sdkmanager "platform-tools" && sdkmanager "ndk-bundle" && sdkmanager "build-tools;33.0.0" "platforms;android-33"
You generally don't need to touch gradle at all with flutter. Is your issue about having to install gradle onto your machine, even if you don't use it directly?
(I used to work on it, or at least tried to before giving up in frustration.)
Out of interest, what blockers did you encounter using Flutter? For me it was much better than native android in terms of development, but it could depend on the usecase.
Yes, you can just grab the zip files. For example like this: https://www.hanshq.net/command-line-android.html#sdk
The code is simple and self explanatory.
class RectangleFlatButton(TouchRippleBehavior, Button): primary_color = get_color_from_hex("#EB8933")
def on_touch_down(self, touch):
collide_point = self.collide_point(touch.x, touch.y)
if collide_point:
touch.grab(self)
self.ripple_show(touch)
return True
return False
def on_touch_up(self, touch):
if touch.grab_current is self:
touch.ungrab(self)
self.ripple_fade()
return True
return False
MainApp().run()
I just remember working with Libgdx back in the days. A game framework made for Android. It however was cleverly designed in that you could just run it on desktop by changing which implementations were used for drawing/sounds/assets. Very nice to work with, could just recompile the app in seconds and test, even hot swap, compared to the other way of building an apk, installing, launching etc which took minutes per iteration.
Also made a simple project on github to show how to do a "loading screen", aka not just freeze while it loads but have a progress bar and interactivity. Somehow it still gets random stars a decade later.
> That will break the back of the duopoly and also make things like this so much easier.
…and so much less secure by giving every application access to everything in my home dir. No, thank you.
But it's not really about sandbox security and file system access. The issue is that the more walls you erect and the tighter you make your sandbox, the harder you will make it for apps to access system resources for legitimate purposes. This is where Android shines as it provides a huge, fine-grained API for apps to access system resources while still making sure they only access what they're allowed to access. On Linux we don't even have that fine-grained an API, let alone the same level of fine-grained control. You either grant an application access to your bluetooth/wifi/… device or you don't.
What's more, all Android apps and their UI have been built around this permission-based system these days. Compare this to Linux where applications still assume they have access to everything by default and you have to work very hard to confine an application while making sure it's still usable and the user is not thrown off by weird error messages.
In other words: The strength of Android (and iOS) is that they built in a tight & fine-grained capability-based system from the get-go and also solved the UI challenges that went along with that. These days, they can count on an entire ecosystem of applications that expect to live (and are usable) in that sandbox.
Regular Linux distributions are lightyears away from that. Personally, I really hope SpectrumOS[2] will make a dent here.
[0]: https://source.android.com/docs/security/app-sandbox
[1]: https://source.android.com/docs/core/permissions/restricted-...
I don't follow what you mean by "give or don't" isn't that how Android works? Like I give file system or drive access to some app so it can pick pictures. Do I know what else it does with that permission?! Just have to trust.
I agree that's an issue but I would say it's a separate one. At least in Android these days you don't have to agree to everything upfront (during installation) but you can choose the permissions you want to grant one by one later during runtime. E.g. when the app wants to access the camera, it asks you for access right there and then and you can also only give it one-time access. That's already been a big UX and security improvement and I'm sure this can be improved even further.
> Like I give file system or drive access to some app so it can pick pictures.
In past versions of Android yes. Nowadays, however, in order for the app to access select photos it no longer needs the general file system access permission. The file picker has become a system component, and by picking photos you grant the app access to the selected files and the selected files only. Of course if the app is, say, a photo gallery app, then it will probably still need access to your entire camera folder (or even the entire file system), not just individual files. In such cases, I at least will probably review the app a bit more carefully.
> Do I know what else it does with that permission?! Just have to trust.
That's always the case when you grant permissions to someone or something. At least, the more fine-grained your permission system is, the more control you have, and the easier it will be for you to build that trust.
In my case I usually disable internet access[0] for apps by default, so that even if they need access to, say, my entire file system, they won't be able to send my files anywhere or do anything shady. Only for select apps that I've reviewed carefully I might also enable internet access.
Either way, I hope we can agree that Android gives you a lot more control over what you allow your apps to do than Linux. In Linux I have to blindly trust all apps at once. It's all or nothing.
[0]: I use GrapheneOS. In regular Android the internet permission is no longer exposed to the user, I think.
In other words: lightweight, useful, cheap - pick two.
(Then gradually rewrite the core in Zig.)
https://github.com/libsdl-org/SDL/blob/main/docs/README-andr...
I wake up every morning and thank God that Flutter exists. I can target Android without dealing with building on years and years of sloppy work.
Sunk-cost fallacy x politics leads to this never being fixed. I don't think Google can fix it, unless hardware fails entirely. There's been years-long politics that culminated in the hardware org swallowing all the software orgs, and each step along the way involved killing off anything different.
Can they eventually throw away Android and replace it with Fuchsia? In the reporting about Fuchsia that I read ages ago, it sounded like it was intended to be an Android replacement but, looking into it again just now, it seems more like an embedded OS for other non-smartphone hardware -- maybe with some (aspirational?) claims of utility on smartphones and tablets.
The problem with replacing a UI toolkit - any toolkit - is that any change to the toolkit requires modification of all software, including third-party software. Typically, when an OS wants to provide a new toolkit, they wrap the existing toolkit in new code. For example, on macOS, UIKit wraps AppKit, and on all Apple platforms SwiftUI is a wrapper around AppKit and UIKit (depending on platform). On Windows, every UI toolkit ultimately is creating "windows" as they are understood by USER[0], which creates corresponding objects in CSRSS and/or the NT kernel, which can then be used to draw on or attach to a GPU. The lowest level UI abstraction either OS provides is the objects supported by their oldest toolkit, and the lowest level programming language you can write apps in is whatever can call it.
Linux is a bit different, because it inherits its windowing model from X11. X shipped with no default toolkit and a stable window server protocol that apps could program against directly, in an era where most GUI OSes[1] didn't have 'servers' or 'protocols'. You populated resource files and called the relevant function calls to make things happen, and those function calls became sacrosanct. Even Windows NT couldn't escape this; it still used USER despite USER being years older than NT.
The best you can do is shim the library - write something more lower level than the old junk and then rewrite the old library in terms of the new one. This is what Xwayland does to make X apps work on Wayland; and it's what Apple did (mostly) with Carbon to give a transition path to Mac OS 8/9 apps on OS X. Google could, say, ship a new Android toolkit that doesn't use Java bindings, and then make Android's Java toolkit a shim to the new native toolkit. However, this still means you have to keep the shim around forever, at least unless you want to start having flag dates and cut-offs. For context, Apple didn't kill Carbon until macOS 10.15 Catalina, and if they hadn't refused to ship Carbon on 64-bit Intel, it probably would still be in macOS today.
[0] An interesting consequence of this is that disabling "legacy input" in games turns off the ability to move the application window since all that code is intimately coupled to every app that has to open a top-level (i.e. not a widget) window.
[1] At the time that would be XEROX Star, the Lisa, and the Macintosh
[2] This is also why Apple will never, ever ship an iPad that can run macOS software in any capacity. Even if they were forced to allow root access and everything else macOS can do. The entire point of the iPad is to force software developers to rewrite their apps for touch, and I suspect their original intent was for the Macintosh to go away like the Apple ][ did.
They hit jackpot with Kubernetes and Docker taking off after their pivot to Go.
And all for what? To satisfy a hobby itch that has no practical benefit? The problem of app developers is almost never the language. Hell, look at how popular web apps are even though JavaScript is the worst language in any sort of widespread usage. The platform is what gets people excited (or frustrated), not a language.
That "everything" contains a pretty big gap.
Just gonna leave this here: https://safecpp.org/draft.html#the-call-for-memory-safety
P.S. Was discussed on HN recently: https://news.ycombinator.com/item?id=41528124
P.P.S. The author has a great YT channel with awesome embedded systems projects: https://www.youtube.com/playlist?list=PLDRymMFQl3Nktk_pjlUP_...
I'd expect Zig to be an easier deal here, with its zero-impedance interface with C.
C++ <-> Rust is much more annoying.
Sure, harder, but not really all that difficult. Run bindgen over the NDK headers and see what happens. Sure, for ergonomics you'll want to write safe Rust wrappers. After that's done once, it's done.
> Rust has fewer cross-compile targets.
Not really an issue here. Rust supports all the targets Android runs on. Natively, even:
$ rustup target list | grep android
aarch64-linux-android
arm-linux-androideabi
armv7-linux-androideabi
i686-linux-android
thumbv7neon-linux-androideabi
x86_64-linux-androidCheck out this blog on zig memory safety: https://www.scattered-thoughts.net/writing/how-safe-is-zig/
(Not my blog, just a blog I found that discusses zig)
Zig is not at 1.0 yet so its a bit behind rust from what iv seen online. One I manage to get C under my belt and get good at writing los level stuff in that language, I might attempt to learn rust or zig.
It would be silly to write low-level software in Java, or high-level software (with exceptions for software which would require a low-level language) in C.
Depends on what kind of low-level stuff.
Yes, of course there are exceptions to every rule. In general, as much as I love the language, Java is not always going to be the best choice.
Java is a piece of crap with JVMs imposing an 8-24 byte overhead per object, which destroys caching, memory footprint, and any chance of low-level optimization. Not only is the overhead bad, it's implementation-dependent, i.e. unpredictable. That, along with lacking SIMD, imposing stupid decisions like bounds checks on all array accesses, making arrays boxed (int[] is not an array of ints, sorry), or using exceptions for control flow, which is the wrong way to use exceptions, is a just part of the big laundry list of why Java is a piece of obsolete crap that nobody serious about low-level hardware programming uses. Java SE/ME is a fucking joke, as is every book I have read about "high performance Java". People who promote Java for low-level hardware programming, real-time systems, and the like, just have absolutely no fucking idea what they're talking about and they get their garbage published only because of the low standards of publishing nowadays. They do get the "Java Champ" badge from Oracle, though. Noobs award other noobs badges, as it turns out.
You want project Valhalla, or more specifically Value Objects, which are in preview [0]. If you really want the highest performance related to cache accesses, you want to arrange things as SoA (struct of arrays) anyway, which has approx 0 object overhead and doesn't require Value Objects.
> Not only is the overhead bad, it's implementation-dependent, i.e. unpredictable.
This is silly. This happens with all other languages, and Java will give you better results on average. Use a different compiler or runtime for your C code, or run it on a different processor architecture, and have fun tuning your code.
> That, along with lacking SIMD
The Vector API [1] is available in preview.
> imposing stupid decisions like bounds checks on all array accesses
It's widely understood that doing the opposite has been perhaps one of the largest mistakes in the history of the industry. JITs elide access checks when safe, and it's easier for them to do with high performance code that doesn't bounce around in memory and thrash cache.
> making arrays boxed (int[] is not an array of ints, sorry)
What does this even mean? An int[] is a linear array of 32-bit int values in memory.
> or using exceptions for control flow, which is the wrong way to use exceptions
Are we now just talking about a small slice of people who write bad code?
> is a just part of the big laundry list of why Java is a piece of obsolete crap
Ah, ok. Have a fine day.
> You want project Valhalla, or more specifically Value Objects, which are in preview [0]. If you really want the highest performance related to cache accesses, you want to arrange things as SoA (struct of arrays) anyway, which has approx 0 object overhead and doesn't require Value Objects.
SoA requires unboxed arrays, otherwise it defeats the purpose. I may have been wrong about int[] being boxed (it seems to be unboxed in most implementations), but the fact that ints still auto-promote to Integer in certain circumstances is just ridiculous for any kind of low-level programming.
It's also hilarious that Value Objects are still in preview. Even C# has had structs (value semantics) since forever.
> This is silly. This happens with all other languages, and Java will give you better results on average. Use a different compiler or runtime for your C code, or run it on a different processor architecture, and have fun tuning your code.
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.
> The Vector API [1] is available in preview.
Also hilarious. It's 2024.
> It's widely understood that doing the opposite has been perhaps one of the largest mistakes in the history of the industry.
Checking every single array access in a tight loop, for example, is stupid. It's the naive, dumb, and inefficient way of doing it (i.e., the Java way.) The right way to do it is to enforce up front that the index may never be out of bounds. Ada helps with this by having user-defined ranges and integer types, for example.
> What does this even mean? An int[] is a linear array of 32-bit int values in memory.
Yes, I think I botched that one, but see also my comment above.
> Are we now just talking about a small slice of people who write bad code?
No, I am talking about Java.
> Ah, ok. Have a fine day.
Oh, and how does Java do low-level systems programming without unsigned integer types, lol? Oh, yeah, you need to cast to/from the next largest integer representation so that you can encode all of the positive values. And you better hope you don't need more than the native size, because then you get fuck-boxed into Integer (see my comment above.) Fucking hilarious, y'all.
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. You need to hope that the JIT will do it, and from my past experience in Android (which this post is about), it doesn't. This is why, for example, if you look at the math library of LWJGL [1], all functions are defined to mutate one of the arguments, they never allocate a new vector to return. This is just completely stupid because mathematical vectors should have value semantics and the compiler optimize the fuck out of them. (Don't get me wrong, I love LWJGL and the guys. This is a criticism of the language, not the library; they are doing the best they can given the language's stupid decisions.)
[1] https://github.com/JOML-CI/JOML/blob/main/src/main/java/org/...
In all fairness, simd<T> in C++ and portable-simd in Rust are both in preview. Not that there is a lack of alternate options there but still.
The languages that do have these APIs stable are Swift, C#, Mojo, Zig and Julia if I’m not mistaken. Stability means different things for some of these as Mojo and Zig are young languages.
Which is why most code that really cares about optimal HW utilization is vectorized explicitly - it's problematic to assert against potential regressions between compiler versions and addressing them is just as brittle.
> 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#loc... 2) https://github.com/vigna/fastutil 3) https://github.com/jOOQ/jOOU
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.
#include <android/configuration.h>
#include <android/looper.h>
#include <android/native_activity.h>Compared to what? And in what way? And then for you to manually recreate it anyway? Like when you need NodeJs, typescript, Turborepo, webpack, babel and a whole list of tools and then you still need scripts to build and deploy?
Yes Maven and Gradle has its problems, but which tool is exactly better? They all just have their pros and cons. Which tool / framework in Go allows you to update a single dependency instead of the 100 that you might need and generates OpenAPI docs for you, etc etc?