Java Development on an Apple M1 – A One Year Review

Probably not asdf's fault, though. I've had multiple issues with gcloud not being compatible with my setup, spamming errors like /tmp/_MEIRZ3igG/libssl.so.1.1

But what asdf doesn't solve, though, is the setup for new devs. Python projects can sometimes take days to get running properly on a machine because of various differences, asdf solves some of it but replaces it with other installation steps instead.

That's what I like about a dockerized setup, if it works one place it works for everyone (almost, nix is probably better).

I think the "Remote-SSH" plugin is a better fit for a comparison though, but @vital101's comment is not wrong.

We have also tried Jetbrains Projector, which is basically a different rendering engine for Java Swing. A remote IDEA instance was rendering the UI through HTML, i.e. you could develop in a browser. It worked relatively well, but there were some issues around copy/paste, etc.

Sounds like they _are_ making fast progress at least.

I noticed I fell out of the "flow" a lot less on M1, because actions that took a few seconds on other machines are now instantaneous.

Regarding the Intellij Idea and Docker, my old 16GB MBP 2015 Mojave was struggling hard and getting very hot with 100K LoC project. I would definitely use the Gateway on old machine aswell.

There seems to be a work around with qemu and UTM but I cannot speak to its performance or how viable this solution is.

But people who use keycloak often have little idea what Java is. They write code in Go and call Keycloak interfaces via REST API. They just need to start that thing and connect to some database.

With docker they'll get it up and running in minutes.

With EAR they'll spend next few days I bet it.

Or you need to try something on another project that uses a different version of your database server. Or you need to pinch-hit on a project that has a half-dozen service dependencies at particular versions, none of which you have installed and running already.

The ability to very easily spin up clean installs of a bunch of services at arbitrary versions is incredibly useful. Containers aren't the only way to do that, but Docker does make it pretty damn convenient.

But often times, our laptop don't have enough memory to perform the build and various tests. So we have to offload that to the CI/CD pipelines.

If I need to test my code locally against a service some other team develops, the only exchange needs to be "here's a docker compose file you can run with one command", not a wiki with shell scripts and other dozens of instructions which were likely outdated 3 years ago.

I remember that first month as being very painful to use the IDE. It was really dramatically slow.

And here’s a post talking about it in the context of C++11: https://www.arangodb.com/2021/02/cpp-memory-model-migrating-...

On x86, a write by core A to memory will be available to core B if core B reads from main memory.

On aarch64, a write by core A will not immediately get published to main memory (will likely stay in cache (L1, L2, etc.), so even if core B tries to read from main memory it won't see the value from core A.

Ultimately aarch64's "weak"(er) memory model is more efficient as the programmer/compiler can make more efficient memory accesses. This results in fewer cache invalidations between cores. The problem in practice is that tons of production code has been written which assumes the x86 memory model. It may also just be a concurrency bug which doesn't manifest on x86 but does on aarch64 like in the post.

Again, this is a simplification of what happens but I think it illustrates the difference to some degree.

If it's more ambient music (like those "lo-fi beats to study to" livestreams that are always running on YouTube) I can usually let that run and be a replacement to the white noise coming from the fan in my room. But I still keep the volume pretty low.

Before people thought Java would save everyone from ever having to think about native dependencies. Turned out not so much, although it works "OK" for desktop these days.

Now everyone thinks Docker is going to save everyone from having to think about native dependencies. In a few years everyone will realize that Docker only works like that when deploying from linux to linux on the same CPU architecture.