Java Development on an Apple M1 – A One Year Review

https://rieckpil.de/java-development-on-an-apple-m1-a-one-year-review/

by rieckpil • 4 years ago

174 168 4 years ago

Nursie• 4 years ago

I bought an Air about a year ago too.

I had similar issues early on with testcontainers but once that was resolved, developing Java on the M1 has been a breeze.

m_st2• 4 years ago

I love my MBA M1. It's the best computer I ever owned. Super fast for the kind of stuff I need it for. The battery seems to be always charged and it is immediately available when opening the lid. And it doesn't even have a fan. Best Mac ever.

murrayhenson• 4 years ago

I just bought an MBA M1 with 16 GB of RAM. I had to check to make sure that it was actually going into sleep mode because the system seems to instantly turn on and unlock when coming out of sleep mode.

It's also cold most of the time; it takes ages to get up to what feels like "room temperature". I'm besmitten.

vbezhenar4• 4 years ago

My issue is that our company uses Gitlab for CI builds and Gitlab doesn't have ARM runners. And I'm the only guy with Macbook, so using some Mac Mini for Gitlab CI runner is not possible. I'm rebuilding images for myself that I'm currently working on, but that's tedious and not very productive spending of time.

Another alternative that I'm currently considering is to rent some VPS in my city and use it as docker host. I'll be dependant on the Internet, so that's not very nice, but might be an option to consider.

I wish Apple would extend Rosetta to VM support. That's really missing piece of puzzle when it comes to migrating to ARM. qemu is not good enough.

easton• 4 years ago

If you have a AWS (or Oracle Cloud has it too) presence, they have ARM VMs you can get. You could probably self-host a build agent on one of those to do your ARM builds.

mindwok• 4 years ago

Gitlab has ARM binaries for Gitlab runner. I can’t speak for the shared runners you get access to on Gitlab.com but you could always run your own runner and connect it to your Gitlab.

nkristoffersen• 4 years ago

We are running gitlab-runner on an M1 Mac Mini now for iOS builds. Runs fine, was a little complicated getting React Native/Fastlane to compile the app but eventually got it running and is creating new builds almost every day. And we are using the Scaleway M1 machine so we can easily do remote management.

random_kris• 4 years ago

Checkout gitpod. This is my usecase for using them

dindresto• 4 years ago

You don't need an ARM runner to produce ARM images. Docker buildx supports building for more than one architecture through qemu: https://github.com/microsoft/azure-pipelines-tasks/issues/12...

qwertox• 4 years ago

I thought building an ARM64 docker image with qemu on a Ryzen 9590X would be a good way to offload building docker images from my Raspberry Pi 4. My benchmarks in building an ARM64 Nginx image was the following:

Ryzen 9590X: 20:09 (20 min 9 sec)

Raspberry Pi 3: 15:46

Raspberry Pi 4 8GB: 4:34

That settled it for me.

KptMarchewa• 4 years ago

I really wish CI companies would step up - they are the missing link now. I run ARM locally and my servers run it too, but I have to work around missing ARM CI step.

At least CircleCI has machine ARM runners but not docker ones.

thiagocsf• 4 years ago

GitLab Runner officially supported binaries are available for the following architectures: x86, AMD64, ARM64, ARM, s390x, ppc64le

https://docs.gitlab.com/runner/install/

You must be talking about shared runners in GitLab.com.

torginus• 4 years ago

It's so weird to see that Java was architected to bend over backwards to be able to run on multiple CPU architectures, which was a feature nobody actually used for decades (well mobile devs did, but they were still targeting a homogenous arch), and now, when there's actually demand for this from the backend side, it doesn't work due to other components in the system.

cbm-vic-20• 4 years ago

I worked on an enterprise software system written in Java, our customers ran it on Solaris, Linux, AIX, and some even ran it on Windows, and developers on OS X. Same binaries, worked everywhere.

jurmous3• 4 years ago

I got the MacBook Pro M1 16GB when it was launched in November 2020. I was losing my previous provided laptop by leaving my previous job and needed to buy one to join a startup program. It was a big gamble but I am the kind of early adopter guy that did not want to miss out on this new CPU fun.

It meant for me that in the beginning IDEs, Java and things like node ran all in Rosetta mode and were very slow. I was almost starting to regret my choice. Sometimes there were Arm fixes committed for things like NodeJS but they were not yet released so I needed to build my own version. Same issues with the JVM to find something able to run smoothly. (Felt that the slowdown was extra painful for JIT like languages) Also for Docker it meant waiting for some months to have something that would work properly but luckily I could manage without at the start. I was happy to see that major blockages improved in some months and for some lagging dependencies I was pushing some fixes myself.

At this moment almost 1.5 years later everything works smoothly. The IDE, Java, Node etc. I still had to navigate around some specific dependencies but the fully native M1 development flow is so smooth compared to my previous Intel MacBook. I am quite happy.

m_st2• 4 years ago

You wrote "and were very slow". And is it faster now? Asking because Rosetta seems to be very fast.

pilif• 4 years ago

Rosetta is fast unless any kind of JITed code is involved. A lot of Java development is happening with tools written in Java for the JVM which is relying a lot on JIT compilation.

The JetBrains IDEs were bordering unusable under Rosetta. They would speed up over time as Rosetta did its work, but it was multiple tens of minutes of slow as molasses until things got better and after each IDE restart you were back at square one.

Thankfully, JetBrains released updates to their products to run on a bundled ARM JVM very quickly

voyager12• 4 years ago

Protip if you have good internet and don't want to configure everything locally: Jetbrains Gateway [1].

At the last company we had Docker, Java 8, Wildfly 10, Gradle 4 and I didn't manage to make it run locally on M1.

I was pleasently surprised with how smooth it was to connect to Ubuntu VM with Jetbrains Gateway. You use native Jetbrains app on your computer (Intellij Idea in my case), but everything is executed and compiled on the remote machine (Ubuntu VM). Another huge upside is that Docker is running on Ubuntu, which is a lot faster than on OSX. Downside is that your are dependant on the Internet ofcourse.

Officially the product is still in Beta, but it worked good enough for me.

[1] https://www.jetbrains.com/remote-development/gateway/

matsemann2• 4 years ago

Ah, very cool. For java dev I haven't yet felt the need to containerize anything, normally mvn clean install works and does everything needed. But for Python I've used remote interpreters through docker in PyCharm lately (since getting a python env installed with wheels & stuff properly is sometimes almost impossible).

VSCode have had some more luck with their frontend/backend architecture making it easier to pull off, glad to see jetbrains is on the move, as I prefer them.

eropple2• 4 years ago

YMMV, but I've had very good luck just using asdf for...pretty much everything, Python included. In a normal week I'll probably touch half a dozen environments--Node, PHP, Python, Java, Ruby, Golang, maybe sometimes dotnet-core--and asdf not only Just Works for me, but has done so without thinking about it for going on three years or so, when stuff like rvm/rbenv changed rapidly enough as to necessitate changing it up to stay on the same page as my teammates.

No relation, just a super happy user.

vital101• 4 years ago

This is similar to how developing with VSCode is on Windows + WSL.

moron4hire• 4 years ago

WSL does not run remotely. It runs in a VM locally.

cstrat• 4 years ago

self hosted https://coder.com/ is amazing.

jhgb• 4 years ago

Emacs+SLIME has worked like this since the beginning.

sz4kerto3• 4 years ago

We're moving our whole company to this product right now. Instead of buying (and upgrading) more and more powerful laptops for our (fully remote) dev team, we just get them whatever thin&light stuff they want, and a dedicated server with large RAM so that they can run the whole test environment easily. There are some rough edges here and there, but it's a game changer.

mhitza• 4 years ago

Thin clients are back on the menu.

I wanted to transition to this development model a year ago, but unfortunately X11 forwarding was slow on mobile connections, and as far as I'm aware (if you know a workaround let me know), on Linux, RDP can't be made to just share a single app, only full desktop sessions.

pjmlp10• 4 years ago

Welcome back to telnet + X Windows into the UNIX development server.

rieckpil3• 4 years ago

Thanks for sharing this product. It looks really promising.

Testcontainers Cloud (https://www.atomicjar.com/2021/11/announcing-testcontainers-...) may be another tool to use for those that only want to "outsource" the container part of running intgeration tests.

rerx4• 4 years ago

Gave this a try a few weeks ago (for CLion with Jetbrains Client, IntelliJ for Java might be further of course) and felt it was still quite lacking. Loads of features weren't there yet. Of the top of my head: no way to use my customized keymap, no git blame annotations, fundamental navigation shortcuts missing (jump back, navigate via file structure), no way to attach the debugger to a process, ...

I went back to remote controlling the full-featured IDE via Projector, their earlier approach too remote development. That works extremely well for what it is. Probably the richer Gateway client will catch up in a while, but not quite yet.

pmulv• 4 years ago

no git blame annotations

Thanks for mentioning this. I was going to give this a try this weekend but that's a dealbreaker for me.

foobarian• 4 years ago

I am able to attach to the remote JVM fine. However the roundtrip makes the QoL features like getting object contents a little slow. But it works!

The main issue I've seen is the gateway/target JVM combo gets wedged in some weird state somehow that persists across retarts and I found myself killing idea processes by hand on the remote server. But hey it's Beta! Works pretty excellent considering.

gjvc• 4 years ago

looks like Projector is somewhat deprecated and removed from the Toolbox app (internal YouTrack item https://youtrack.jetbrains.com/issue/TBX-7455)

they do state on this page https://lp.jetbrains.com/projector/ "If you're not sure which solution you should choose, please consider using Gateway."

mhoad2• 4 years ago

As an alternative I’ve had great experiences so far with GitHub’s Codespaces.

I couldn’t see myself going back to just running everything outside of at least some containerised environment at a minimum even if not fully remote.

I do a bunch of front end web stuff as well and now the thought of just running npm on my local machine gives me the chills. It’s akin to attending an orgy without a condom :)

pc86• 4 years ago

No it's not

ta9883• 4 years ago

Jetbrains Gateway doesn't work on M1. Unless you modify it heavily and you control it from the command line.

sz4kerto3• 4 years ago

It definitely does, without any kind of extra configuration or work.

hbn3• 4 years ago

It's good to have the option, but ideally if I buy a really nice new computer, I'd like to actually be taking advantage of that hardware I paid for!

ChuckNorris892• 4 years ago

Yeah, same. I don't get the point of buying an expensive and benchmark crushing piece of ARM hardware for some development work if it has the utility of a $200 Chromebook where you have to SSH into powerful X86 machines to actually achieve your development goal.

sixothree• 4 years ago

Doesn't mean you can't run that Ubuntu instance in a VM on the same machine. Wait does it? Can you run VMs on these guys?

olavgg• 4 years ago

Thank you for your suggestion, I just gave this a try, and it's almost there but there are still some rough edges. It needs to mature a little bit more.

Though this got me thinking a little bit, I have ordered a M1 Max 32GB which I have been waiting for over 5 months now. I am actually looking into getting the M1 air with 8GB as I think it will suffice for my Java development. I don't need to run VM's on that machine.

I'm gonna think about this through this weekend. I don't really need the firepower from the M1 Max as it has similar single core performance to the M1 air. And if this product matures, I will really not need that much RAM either.

vonseel• 4 years ago

You should definitely give the M1 MBA a try and return it if it doesn’t work well. Mine is only 8Gb RAM too, but I haven’t noticed paging slowdowns or any problems.

wccrawford• 4 years ago

I just tried to connect to my Intel OSX with Gateway and it told me that OSX/x86_64 isn't a valid combination and refused to connect.

I was hoping to use it to do most of my stuff remotely, instead of a remote client or a mouse/kb sharing program like Barrier.

shabazahmed• 4 years ago

VScode remote containers are much more flexible.

digisign5• 4 years ago

Do tell, how so?

andybak• 4 years ago

The promise of Docker was "develop on the same configuration you deploy on".

Is swapping Intel for Arm64 transparent enough to preserve the peace of mind back-end developers need, here?

Maybe with Java the answer is yes, but how about non-java environments?

keyle• 4 years ago

Transparent here... No Java though.

coder543• 4 years ago

Docker's promise was never about processor architecture. In most cases, I would say developers have been working with Docker locally on a different processor architecture than what they deploy to in production. Their local machine might not have AVX-512 instructions, but the production machine might... or any number of the small variations of AMD64 that exist. If you're not careful, you can end up compiling binaries that work on your machine, but don't work in production, all on AMD64.

These days, Docker supports multiarch images, so it's fairly trivial to build one image that supports with AMD64 and ARM64 transparently. CI tools like CircleCI support runners for AMD64 and ARM64, so you can even run your test suite on both architectures for additional confidence, if needed.

For me, Docker containers have always been about reproducibility of builds (which some people will argue about, but it does a good job 99% of the time) and consistency in deployment. You don't need to have an artisanal deployment methodology for each application... you just need to have a way to deploy docker containers. Even for single static binaries like Go projects often produce, wrapping them in a docker container just makes it easier to abstract away the deployment problems across projects. For more difficult to deploy languages like Python, you get similar benefits to having a single static binary by wrapping all the dependencies up into a neat little container.

Plus, once you have a standard unit of deployment like a docker container, you gain access to the broader ecosystem of container tools with minimal effort, such as running each container within a Firecracker microVM if you need isolation.

simongray• 4 years ago

Thanks for saying what needs to be said. I can't stand the greybeards arguing about Docker whenever it's mentioned.

danw19793• 4 years ago

All other development tools that we use on a daily basis either provide an arm64 build or the emulated x64 version works fine: IntelliJ IDEA, Visual Studio Code, Slack, Notion, Docker for Mac, Spotify, Firefox, Microsoft Teams, Postman.

I had a little chuckle at Spotify being in the list of developer tools. I feel the same. No techno, no code.

rieckpil3• 4 years ago

No good code was ever written while not listening to music :D

saurik• 4 years ago

I mean, the study I remember (from when I was in some class 20 years ago or something, where we would have analyzed this sort of paper) showed that developers listening to music 1) completed the tasks at the same rate as the developers who were not listening to music, 2) reported the task being less boring than the developers who were not listening to music, and... 3) were much much less likely to notice that the code they had been asked to write was an elaborate maze of math that could be replaced with "return 0"; I thereby only listen to music while coding when I need to keep my morale up typing something I already pre-planned myself.

danw19793• 4 years ago

And what’s the coffee machine running too ? wouldn’t be surprised to see armv7 in use there.

bjterry• 4 years ago

From Brian Hook[0], who worked with John Carmack at id Software:

I remember Carmack talking about productivity measurement. While working he would play a CD, and if he was not being productive, he'd pause the CD player. This meant any time someone came into his office to ask him a question or he checked email he'd pause the CD player. He'd then measure his output for the day by how many times he played the CD (or something like that -- maybe it was how far he got down into his CD stack). I distinctly remember him saying "So if I get up to go to the bathroom, I pause the player".
You know what's pretty hardcore? Thinking that going to the bathroom is essentially the same as fucking off.

0: http://bookofhook.blogspot.com/2013/03/smart-guy-productivit...

cedricziel• 4 years ago

I'm a bit surprised nobody mentions the `--platform` argument that docker accepts to emulate a different architecture per container. It's a very smooth experience if you're reliant on 3rd party images.

Available through compose as well.

spyremeown• 4 years ago

I worked with cross-compiling containers. The compiling times were... bad. Our x86 build took like, two minutes (this was a very small and lean C++ application). The arm32v7 ones took upwards of 30 minutes.

the_svd_doctor• 4 years ago

Same experience. Beefy machine, takes 45 minutes to compile cmake using a ppc64le container on an x86_64 host.

heffer• 4 years ago

Works the other way around as well: Compile platform independent code (such as Java) on --platform=$BUILDPLATFORM in a build stage and then copy into containers that are --platform=$TARGETPLATFORM. That way your build only runs once, natively, but you can produce the correct runtime containers for each architecture rather quickly.

fancyfredbot2• 4 years ago

Was nobody else surprised that this article about Java development focuses so much on CPU architectures?

I realize it's mostly talking about testing infrastructure rather than Java code but it feels sad that we end up here - I remember Java's top selling point being "write once run anywhere" and I genuinely believed the JVM would shield you from most issues with CPU architectures. But it seems like they managed to sneak back in through the back door.

pearjuice• 4 years ago

95% of the article is about getting Docker to run properly on M1 - not Java. The JVM works fine.

jurmous3• 4 years ago

It seems that quite some dependencies like for networking, databases etc use natively build code internally using JNI. If those new targets like Mac arm64 are not added, those dependencies don't load. I can remember for example the Google Protobuf JVM package which uses the C++ written Protobuf library internally. It took quite some time before people inside Google had M1 machines and were building the JVM library too for M1.

It seems that those CPU architectures indeed sneak back through a back door... The same on Android, there you have also many libraries which need to be build and published for specific architectures. But luckily new architectures are not added regularly.

pulse72• 4 years ago

Yet another Java criticism here on HN? For every new supported CPU architecture you need time for "things to stabilize"...

freemint• 4 years ago

You might want to read the article.

matwood• 4 years ago

The JVM has worked fine on the M1 from almost day 1. I have workloads running on AWS Graviton without issue. I'm sure there was work getting the JVMs up and running on ARM initially, but as a user who builds on top of the JVM, they have worked great for me.

After skimming the article, it looks like it's mostly another long complaint about Docker which has been discussed many times at this point.

bitcharmer• 4 years ago

It's quite expected to see early teething issues when you roll out a new CPU and try to use existing software on it. This has nothing to do with java.

exabrial2• 4 years ago

Reading the article, it appears the actual problem is actually Docker, not the JVM.

fancyfredbot2• 4 years ago

Yes, that's kind of what I meant by sneaking in through the backdoor. An article supposedly about Java development focuses on all the non-JVM dependencies. You don't need to build things in this way. Is this how everyone works these days? It surprised me that nobody else was commenting on this (edit: the comment from pjmlp is basically saying what I was thinking)

rvz• 4 years ago

Judging from the comments here and the article, it reads to me that perhaps staying on Intel Macs, waiting for the developer ecosystem to catch up and skipping the early M1 models (November 2020) was a very smart decision to make rather than spending months fighting with your tools.

Unless you want to wait 6 months or even a year to do any work reliably without these 'issues'. Even by then a more faster machine would be worth buying anyway.

foobarbaz33• 4 years ago

Agree, waiting has paid off for late M1 adopters. The software ecosystem has smoothed out most of the hiccups.

And now there is the mac studio, M1 ultra, 128GB ram, 64 cores. An absolute beast of a machine. Fits in a backpack, so it's just as portable as a laptop assuming you work from docking stations anyway.

lowbloodsugar2• 4 years ago

I have an M1 Max, with only 64GB and only 10 cores (the 64 cores in the Ultra are GPU cores, not CPU cores). For a software developer, it is probably fast enough, and I can use it anywhere. I build Rust, and build times aren't a problem. Certainly better than my i9 Intel MBP.

jlengrand2• 4 years ago

One thing that I haven't seen mentioned in the article, which I find a great news is that GraalVM support is also finally coming any time now : https://twitter.com/alina_yurenko/status/1506192755235696644

rieckpil3• 4 years ago

Thanks for this hint :) I'll add it to the article

jlengrand2• 4 years ago

Good article BTW! Very useful :)

jdminhbg• 4 years ago

It's available: https://twitter.com/fniephaus/status/1507022087277334530

pjmlp10• 4 years ago

Here is the thing, maybe you don't need Docker to use Java, which was invented exactly to abstract the underlying OS and CPU architecture (and isn't the only one at that game).

Even worse, given that Docker and Kubernetes basically take Java/.NET application servers to other programming languages.

Talk about fitting square pegs into round holes.

vbezhenar4• 4 years ago

You don’t “need” docker at all. But it makes things easier. You can build any application as a self-contained executable or directory with executable and related files. But it turned out it was not enough.

pjmlp10• 4 years ago

In 99% of the cases a EAR file + JDBC connection is enough.

otterley4• 4 years ago

To get the best performance, many Java applications, especially network-intensive ones, use native libraries. Netty is a perfect example, and is used by a lot of projects.

Even worse, given that Docker and Kubernetes basically take Java/.NET application servers to other programming languages.

No they don’t. Not sure what you intended to convey here.

pjmlp10• 4 years ago

Package them inside of shared libraries of the Application container, or use a multitarget JAR/WAR/EAR file.

yoden3• 4 years ago

Many (basically all?) Java libraries that use native code have pre-compiled code for all platforms. They'll just work on all platforms.

We've been upgrading our dependencies for arm64 support; for the most part it is as simple as updating our pined version to a newer version of the jar. Sometimes the native code is in a separate jar so you just add it (opencv works this way).

yusefnapora• 4 years ago

It's not so much about the Java code itself. When your Java app needs to talk to a database, it's convenient to be able to write integration tests against a running instance of the real DB. Ideally you'd also have a light-weight mock DB for unit tests, but some things only show up against the real deal. I guess you _could_ build that kind of test environment without containers, but I sure wouldn't want to.

pjmlp10• 4 years ago

That is what JDBC and JNDI are for.

dewey2• 4 years ago

It's not so much about the Java code itself.

But how is that related to the database? Wouldn't you just run the database in a container as a side car?

nicoburns2• 4 years ago

If you're using an open source database like MySQL or Postgres it's pretty trivial to do this without containers. All you need is ~10 lines of SQL to create a new database and database user on your single local database instance. I don't understand why anyone would use a different database for testing and production. As far as I'm concerned, Postgres/MySQL are lightweight. I certainly have them running permanently on my machine and they use almost no resources when not in active use.

didip2• 4 years ago

I have to hard disagree here. Plenty of Maven projects build are not immutable. They are buggy and not reliable when producing artifacts.

Also, Java 9 broke backward compatibility promise, and Java 17 broke it further by disabling a lot of default modules. Docker helps A/B testing multiple variation of JDK for our builds.

We definitely need Docker. It's a live saver for so many of our Java projects.

Not to mention, every single CI/CD engineers in a big company will mandate Docker as a packaging requirement anyway. So why not do it right and use Docker anyway?

nicoburns2• 4 years ago

Also, Java 9 broke backward compatibility promise, and Java 17 broke it further by disabling a lot of default modules. Docker helps A/B testing multiple variation of JDK for our builds.

Does Java not have a version manager that lets you install multiple JDKs side-by-side and easily switch between them? For ecosystems I'm familiar with like Node.js and Rust this as is simple as a single command to install a given version and adding a text file with the required version to each repository(/directory) (it then gets used automatically when running code in that repo).

The answer for why not use Docker for development if you're using in production (on Windows/macOS) is that it's much slower. So the same reason that I have separate debug (fast compile time) and release (optimised) builds. If you're on Linux then Docker is great.

pjmlp10• 4 years ago

I used containers, before many Docker advocates were out of kindergarten, starting with HP-UX Vault.

No we don't need them.

yoden3• 4 years ago

Yeah, it's hilarious to see Docker so misused. Most Java/.Net environments will just work on any system without Docker. Adding Docker gives you a bunch of native platform and emulation pains you wouldn't have otherwise.

paxys2• 4 years ago

This almost always falls apart when you are developing two projects with conflicting stacks simultaneously. Can I run two JVMs with different versions and configurations? Multiple MySQL servers? Multiple web servers? And if I make a change to any one of them, how do I roll it out to my entire dev team? What would take endless tinkering becomes trivial with one Docker script.

RandyRanderson2• 4 years ago

Answers to your questions:

Yes, Yes, Yes, often teams use shells script, gradle or maven.

The same config you'd put in the docker yaml or whatever would go into the maven or whatever config except that the devs would be familiar with the existing tools and wouldn't spend countless hours mucking about with docker files.

Also unless you're using docker on x86 AND linux, likely things will not work or at least you'll run into mem, or perf or other compat issues.

After working with Java/Python for years, I had forgotten about the hell people go through with other langs deploying on diverse OSes/arches.

pjmlp10• 4 years ago

Yes, you can.

I have been coding since 1986.

There was a time before Docker.

layer8• 4 years ago

The article is more about docker than about Java.

tytrdev2• 4 years ago

Java for old folks

I guess their abacus broke

This is a haiku

Koshkin• 4 years ago

Too funny, this. (I still consider Java, and Javascript along with it, a new kid on the block. The language is still evolving at a rapid pace - unlike C, for example - with the kinks still being worked out.)

vincent-manis• 4 years ago

Yes. I am considering moving from Fortran II to Fortran IV. Don't want to be rushed about making a decision, though.

AtlasBarfed• 4 years ago

The Big JS Lie

We Fixed it in this release

Worse Worse Is Better

tytrdev2• 4 years ago

Old one reads poem

They're angry, a lack of Ken

Clicks downward arrow

exabrial2• 4 years ago

Just want to say thanks for writing this up!

MandieD• 4 years ago

Or you could run your containers on BlueMix…

Tasteless jokes aside, great seeing you writing useful stuff for the world in your post “large, Franconia-based manufacturer” life!

morpheuskafka• 4 years ago

I remember last fall (when I got an M1 MBP for the first time, but the chip itself had been out for a year and sold through the school's laptop program) in a CS class I was the only one who could figure out how to make the JavaFX assignments work on M1. They would all load the GUI okay but crash as soon as anything was clicked.

The error message was from the native JDK code, so was not very useful, I just gave up and searched the bug tracker for "M1" until I found something that looked close. IIRC it was some weird error caused by code that was objectively wrong for several years, but the race/error condition had never been observed on an Intel machine, if I remember correctly. Thankfully it was in an EA build of OpenJDK, otherwise I probably would have given up and thrown up a VM in the cloud to run it in.

nick_2• 4 years ago

I suspect a huge number of these kinds of bugs exist in production software, and will be brought to light by the "weak"(er) memory model of aarch64.

dlivingston• 4 years ago

I'm curious, can you expand on aarch64's 'weaker memory model'?

thatjoeoverthr2• 4 years ago

That reminds me of an experience targeting x86 Windows and G3 Mac (IBM 750 PowerPC) with some C networking code (a thin client). Immediately I got a “bus error” on the Mac, even though it worked fine on the Penguin III. I found the problem was a misaligned memory access - a blatant mistake on my part - that the Penguin III just covered for somehow. You can read this as an example of the robustness principle, but I recall feeling I’d prefer the CPU just tell me something is wrong and not cover it up.

thatjoeoverthr2• 4 years ago

Wow “penguin III” thanks autocorrect

mark_l_watson• 4 years ago

Useful article, thanks for writing it.

I have had an M1 MacBook Pro for over a year and it did take extra work building SBCL Common Lisp from scratch, setting up brew for M1 architecture, and experimenting what would work for me on Docker.

M1 Macs are awesome, I love mine, but I understand devs who want to stick with Intel.

One of the reasons M1 is easy for me is that I do a lot of dev using mosh/ssh, tmux, Emacs on Intel VPSs.

lowbloodsugar2• 4 years ago

TLDR: 90% of article was docker issues. Java works fine. Some deps use JNA (native code) and (surprise) you need the right arch for them.

smrtinsert2• 4 years ago

I've been enjoying my 2020 m1 as my local node, spring boot and some jupyter playground. It's a wonderful device. I've noticed there's a lot of momentum to supply m1 related fixes, for example, I think a kafka admin tool I was using just provided an update for it, so things are moving along.

I think around next year I might considering asking for an m1 upgrade for my aging mbpro.

jwr• 4 years ago

As a Clojure developer, I'm very grateful for this information. Thank you! My development environment is OpenJDK plus a bunch of Docker containers (I use Docker extensively to contain/freeze various dumpster fires like projects that use npm and thus restore sanity to long-term development).

I'm still afraid to make the jump to M1.

i386• 4 years ago

Should be retitled s/Java/Docker/

Java Development on an Apple M1 – A One Year Review

Related Stories