4 ms·

I find this hard to accept. Doesn't Apple do pre-release testing of their updates? How the release process looks like? News like these are the major reason why

I find this hard to accept. Doesn't Apple do pre-release testing of their updates? How the release process looks like? News like these are the major reason why I apply updates only after long periods of waiting if anything blows up for others. Why companies use their userbase as testers?

jbverschoor 3y ago
[flagged]
- agsnu 3y ago
  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.
  - jbverschoor 3y ago
    Please read the actual bugreport instead of an article written my Oracle's PM who really does not want the crap on his account.
  - jbverschoor 3y ago
    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)
    - agsnu 3y ago
      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.
      - jbverschoor 3y ago
        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.
- bingbingbing777 3y ago
  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?
  - fractalb 3y ago
    Apple should not be at fault! As simple as that.
- dboreham 3y ago
  Definitely Apple.
- daghamm 3y ago
  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.
  - self_awareness 3y ago
    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/entitlements/com_apple_security_cs_allow-jit https://developer.apple.com/documentation/bundleresources/en...
  - jbverschoor 3y ago
    I did and also the bugreport. https://bugs.java.com/bugdatabase/view_bug?bug_id=8327860 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.
  - grodriguez100 3y ago
    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.
qwertimus 3y ago
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.
- angulardragon03 3y ago
  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.
t-sauer 3y ago
> 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.
- tchbnl 3y ago
  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.
  - t-sauer 3y ago
    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.
    - xcv123 3y ago
      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.
      - usrusr 3y ago
        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.

jbverschoor 3y ago

[flagged]

agsnu 3y ago
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.
- jbverschoor 3y ago
  Please read the actual bugreport instead of an article written my Oracle's PM who really does not want the crap on his account.
- jbverschoor 3y ago
  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)
  - agsnu 3y ago
    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.
    - jbverschoor 3y ago
      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.
bingbingbing777 3y ago
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?
- fractalb 3y ago
  Apple should not be at fault! As simple as that.
dboreham 3y ago
Definitely Apple.
daghamm 3y ago
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.
- self_awareness 3y ago
  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/entitlements/com_apple_security_cs_allow-jit https://developer.apple.com/documentation/bundleresources/en...
- jbverschoor 3y ago
  I did and also the bugreport. https://bugs.java.com/bugdatabase/view_bug?bug_id=8327860 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.
- grodriguez100 3y ago
  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.

qwertimus 3y ago

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.

angulardragon03 3y ago
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.

t-sauer 3y ago

> 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.

tchbnl 3y ago
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.
- t-sauer 3y ago
  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.
  - xcv123 3y ago
    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.
    - usrusr 3y ago
      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.