At least they could have provided a path back to the old behavior.
That probably needs to be qualified with "Oracle JVM Java applications" because I've had many hours of running Minecraft on macOS 14.4 under Zulu's JVM (a pre-14.4 release which means it doesn't have any workarounds) without any issues.
"all Java based applications are crashing" is a false statement either way.
And on the SDK side, they need to use whatever InteliJ requires.
This is like arguing to allow the guy who can't drive and just pin-balls his way down the freeway bouncing of other cars, because to prevent him from driving would be to take away his personal freedoms.
So, if we want a tortured metaphor what JVM is doing is like trying to pass a turnstile to see if the pass is still valid so that on the happy path it saves the extra check. Now Apple decided that instead of just showing a red X and letting you buy a new pass, in the future you get shot in the back of the head if you try with an invalid pass.
That doesn't mean it doesn't happen.
Are you suggesting that the approach taken here was at one point a documented acceptable approach, according to Apple?
Because explicit checks on every memory access (pointer dereference) makes Java significantly slower, even with compiler optimisations to remove redundant checks[1]. Memory protection is a fundamental, very useful, hardware feature and it's perfectly reasonable for user space language runtimes to take advantage of it.
Or, to put it another way, SIGSEGV has been a part of Unix-family OSes for decades. It works perfectly fine on Linux and Windows and there's no reason it shouldn't work on macOS.
[1] (Many years ago I worked on a cross-platform implementation of the Java runtime and wrote much of the threads and signal handling code. We had an option to enable explicit memory checks, which got us up and running faster on new platforms where the SIGSEGV handlers hadn't been written yet. From memory this made everything something like 30-50% slower, so it was definitely worthwhile to implement SIGSEGV handling. In our case SIGSEGV handlers were used both as part of the garbage collector/memory management and to implement Java's NullPointerException)
This isn’t just any old thread triggering SIGKILL, it’s the JIT thread privileged to write to executable pages that is performing illegal memory accesses. That’s typically a sign of a bug, and allowing a thread with write access to executable pages to continue executing after that is a security risk.
But I know of other language runtimes that take advantage of installing signal handlers for SIGBUS/SIGSEGV to detect when they overflow a page so they can allocate more memory, etc. This saves from having to do an explicit overflow check on every allocation. Those threads aren’t given privilege to write to executable memory, so they’re not seeing this issue…
So this sounds like a narrow design problem the JVM is facing with their JIT thread. This blog doesn’t explain why their JIT thread needs to make illegal memory accesses instead of an explicit check.