Strangely, the issue wasn't present in pre-release builds. I agree though, Apple's internal testing before final release should have picked this up.

There is some sample C code to test with, and the issue is actually in the pre-releases. It’s just not in the first couple.

> News like these are the major reason why I apply updates only after long periods of waiting if anything blows up for others.

But then you are accepting that you are running an exploitable OS since you are lacking the latest security fixes. Not sure if that‘s an acceptable tradeoff.

Apple doesn't EOL the last OS version when the latest comes out. I think they mean they wait a few months to make sure all the issues have been worked out.

But that only works if you stick to old majors. At this point Sonoma is out for almost 6 months, so even if you waited a few months to upgrade to Sonoma you are out of luck now. You are either stuck on 14.3 without security fixes or you upgrade to 14.4.

What's the difference? Wait a month (or whatever) before upgrading to the next major or minor release.

My work laptop is stuck on 14.3 for a few weeks until they fix this issue. So what? Actual security risk is practically zero. Whereas if I update to 14.4 today the risk is that I can't do my job.

The difference, if I read gp correctly, is that an older major release would still get new security updates when necessary, but if you already are on the current major, which had been out without this problem for quite a while, you will only see security updates bundled with minor feature changes like the one that introduced the JVM incompatibility.

Not really an Apple-specific problem, it could hit anyone who supports multiple versions without opening that can of worms of allowing completely free mix&match of fixes and updates.

No difference to me. It's an OS update. My policy is to wait before installing any OS update on my work Mac, whether its major or minor. Just wait at least a month. So far I have avoided all of these bullshit issues over several years of updates.

The difference is those who still waited on the major update ("almost 6 months") would still be able to jump on some 13.x.y security fix on short notice, without breaking their JVM, whereas people already on 14.x who can't work without JVM are cut off for the time being.

Still no difference. I would not update to 13.x.y until at least a month later. Defer all updates.

This isn't Apple.

Some software suppliers have a tendency to not react to any changes to an OS, because they assume the OS will create workarounds for them.

FTFA:

> The issue was not present in the early access releases for macOS 14.4, so it was discovered only after Apple released the update.

There were some security fixes that were marked as under active exploitation in macOS 14.4, so my money is on those landing very steep close to the release date and this being fallout from that.

FTBR:

"It is also successful on the previous versions of Sonoma" (no mention of EA)

"It could not be reproduced on 23-ea+13, 22+36-2370" (EA versions of Java)

Right so it’s present in all shipping versions of Java back to at least 8, and the reproduction case works fine on Sonoma pre-14.4. Ergo, Apple changed something in 14.4 (a minor patch release), and it broke something in Java. I’m not sure what point you’re trying to make.

It’s possible that Java was doing something very weird, maybe undocumented/unsupported; but it’s not clear how this is anything other than Apple making a change (which I don’t see documented in their release notes) and breaking users.

Yes, pre 14.4 (14.3.1 to be exact) but NOT early access of macos. The whole thread and Oracle's blogpost is about that it "suddenly broke but it was still working in a preview release of macos".

Java DOES work with an EA version of Java according to the bugtrackers.

Oracle's PM doesn't know what's going on and is mixing things up.

Please read the actual bugreport instead of an article written my Oracle's PM who really does not want the crap on his account.

So I can release breaking changes to my API and expect consumers (who are software suppliers themselves) and it's their fault for not instantly updating their code? How is this not Apple when they were the ones that broke it?

Apple should not be at fault! As simple as that.

Did you read Oracles post?

"The issue was not present in the early access releases for macOS 14.4, so it was discovered only after Apple released the update."

JVM generates code on the fly, which normal applications are not allowed to do. So java by definition receives special treatment from the OS, which OSX seem to have broken now.

I did and also the bugreport.

https://bugs.java.com/bugdatabase/view_bug?bug_id=8327860

It says that "It is also successful on the previous versions of Sonoma", no mention of EA.

In the bug report it says it's actually not reproducable with an eary access version of Java "It could not be reproduced on 23-ea+13, 22+36-2370"

TBF I'd rather not take Oracle's Product Managment's word for granted.

It's not that Java has a special treatment, but all applications who "request it" are allowed (for example also JavaScript engines in browsers).

https://developer.apple.com/documentation/bundleresources/en...

There is no “special treatment for Java”. This is a well known technique that has been used for ages in the implementation of JITs. The behavior it relies on is specified by POSIX.

Definitely Apple.