Anyone who’s complaining about that with python has never inherited a large *ruby* project
Java, python, c… can we at least all agree that ruby should have been strangled in its crib?
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Oracle Warns macOS 14.4 Can Cause Java to Terminate Unexpectedly
- Thread starter MacRumors
- Start date
- Sort by reaction score
Java, python, c… can we at least all agree that ruby should have been strangled in its crib?
No way either one of those will die off as they are the most popular.But... yeah. There are a few server-side technologies which are in wide use, but that I personally wouldn't mind seeing die off. Java is one. Node is another.
63% of developers use JavaScript, 30% of developers use Java.
Python is 49% - the only language in competition. Everything else is under 30%. Not sure why they list HTML/CSS, Bash Shell or SQL as programming languages. But, hey.
Most used languages among software developers globally 2023 | Statista
As of 2022, JavaScript and HTML/CSS were the most commonly used programming languages among software developers around the world, with more than 63.6 percent of respondents stating that they used JavaScript and just around 53 percent using HTML/CSS.
www.statista.com
That's Apple for you. One quarter numbers are meaningless because the sales typically spike after new model release. Then in 2023, in the third quarter Apple PC Shipments Dropped 2X More Than Any Other Manufacturer In Q3. Apple share dropped to 10.6% which is close to where it was for the last decade. Combine this with 0% share in non-PC computer market (servers, industrial computers etc.) and it becomes clear that Macs remain a marginal player in computer industry.Afterthought eh :
Apple's PC market share in the U.S. 2013-2023 | Statista
In the fourth quarter of 2023, Apple shipped 16.1 percent of all PC units in the United States.
Everyone can pull stats from the internet
Apple has been a marginal player in the computer industry since 1976 (48 years). Nothing's changed.
Just stepping out out of this topic briefly to explain why Macs shipments have been impacted in your reference link.
======
The quarter ending July 1st 2023 was still being affected by manufacturing/transporting issues from China after covid shutdowns of their cities ended in Dec 2022, and Apple was using other manufacturing sites. Combine that with the lack of Apple product announcements from Jan 17 2023 to WWDC 2023, and you see Apple was clearly still struggling to get things normalized a half year later. Also during this first half of 2023 period Silicon Valley had a mini-recession that meant companies were't buying computers as much as they usually do instead were laying off excess worker they accumulated during covid period.
Layoffs and AI Are Changing Tech’s Once-Invincible Job Market
A look at who’s unemployed, who should be worried and who’s more valuable than ever.
www.bloomberg.com
We are still waiting for Apple even this day to update a number of Macs to M3 family. Mac Pro, Mac mini, Mac Studio. 2024 shows products starting to normalize (sales volume) if Apple will update them.
=======
As said earlier this MacOS 14.4 issue should be easy to deterring/fix as it was working with earlier versions of 14.4 betas.
Last edited:
Anyone who’s complaining about that with python has never inherited a large *ruby* project
Java, python, c… can we at least all agree that ruby should have been strangled in its crib?
I have so much frustration with ruby right now and to be more exact Apple install of it. I lost 2 days trying to unscrew up my machine and trying to get my ruby install corrected. I think 2 full nukes of ruby and homebrew and then some other random scripts put in to get everything to point to the right version of ruby.
Apple install of ruby is half baked and gets really screwing with Rosetta and does not go deep enough to figure out the right version of ruby to use….
Flipping from Rosetta terminal and ruby to having to back to arm god what a nightmare and I am still pretty sure I have not fixed everything right. I am just hoping this time I have gotten all my tools pointing to Homebrew and not Apple POS.
Ummmmmm....
Pycharm is one of the most popular IDEs for Python.
Wanna take a guess at what its boot runtime environment is?
Apples and oranges. Our backend group writes overwhelmingly in Python, but we don't kid ourselves about Python's strengths and weaknesses. And we have a few Java devs who work on things we have no intention of making obsolete any time soon.
Consider the source. It’s not coming from experienced professional developers.
Anyone who’s complaining about that with python has never inherited a large *ruby* project
Java, python, c… can we at least all agree that ruby should have been strangled in its crib?
I'm with you on that one! 🤣
It's not really though. Firstly it changes so quickly it's like trying to piss on an ant from a moving train. Secondly the open source ecosystem around it is absolute garbage. Then there's the telemetry and the stewardship of Microsoft, which were objectionable enough that they were deleting comments off the github thread from people just for stating their position.
No thanks.
OSX and Java have a long and sordid history. J2EE is fine for enterprise apps, but as a front end? Second only to electron for 'bad least common denominator UX'.
But in this case, my first question was, did Oracle test it during the dev releases? I suspect not.
But in this case, my first question was, did Oracle test it during the dev releases? I suspect not.
Right. Now days I just install OpenJDK using brew, which works great and is the reference implementation of Java. But this isn't a bug in Java, it's caused by a bug or change in behaviour of macOS memory management.
Runtimes and virtual machines which implement their own memory management (such as Java's garbage collector) need to receive segmentation faults ("SIGSEGV", in Unix-family OSs) from the OS so they can handle them in their own way.
In some circumstances, it seems macOS 14.4 isn't sending those SIGSEGV signals to Java as it should, but is just killing the Java runtime entirely.
There are ~ 7M professional Java developers in the world. Among them Macs are very popular. I would estimate that this bug affects 1-2M people.
According to Oracle: "The issue was not present in the early access releases for macOS 14.4, so it was discovered only after Apple released the update."
This appears to be a bug in macOS that is crashing Java, not a bug in Java itself.
It may shock you to learn that much of macOS is still written in Objective-C (40 years old), C++ (45 years old), and C (55 years old).
Last edited:
Duh...try reading the article first. The change wasn't in any pre-release versions. It showed up first in the production release. There was nothing for Oracle (or any of the many other Java implementers) to test.
If you're a professional Java developer, SDKMAN is really the way to manage Java installations nowadays, IMHO. I have to switch back and forth between jdk17 & jdk21 (I use Temurin), and GraalVM for both versions all the time (our Github CI builds use all of these). Without SDKMAN I'd go nuts. That and Testcontainers Cloud make life much easier.
Last edited:
As a Java developer since 1996, and as a software architect that has designed a major system based on Java (on the back end), used by millions or people, I can say ... yeah. Oracle has failed to impress since their takeover of Java. Oracle isn't well known as a reliable narrator of its own business practices.
Last edited:
You haven't used GraalVM for cloud microservices and/or serverless functions?
To build on that -- this is the problem with Apple's dev team/model. They don't understand releases. Implicitly they operate under a rolling/subscription model update schema ignoring the cost on their users of broken releases and updates. Additionally since the fixes are always rolled into bigger updates, we don't really get a stable release until Apple's attention finally moves to the next release.
The idea behind a release candidate is that nothing changes between the release candidate and the released version except the build # and version text. If the RC breaks something major, you fix it and release another RC to make sure you didn't break anything major. I know that's old fashioned but here we are at macOS 14.4 -- the 4th subversion to the 23rd major release -- with new things breaking while major things stay broken release after release.
And this is where Apple lacks strategic alignment. If Apple's vision for the VisionPro is enterprise/hospital/etc sales, this won't fly. The reason why the iPhone made it into the enterprise is that Apple captured the consumer market first putting pressure on IT/etc from above and below. Given the terrible alternatives at the time, all they had to do then was throw in a few bones for the enterprise, and Blackberry, et all were dead. However, if Apple tries to skip that step while not addressing enterprise needs (like stability in the dev/release process), I bet their success in these markets will be middling at best.