I really don't want to upvote this sentiment but I must anyway.
The fact is, despite Oracle being a menace to the tech industry, Java under their watch is thriving. Which is weird, because I don't know anyone who gives them money for Java. I'm genuinely curious who these companies are and what their incentives are!
Java gets more hate than it deserves. "There are languages everyone complains about and languages nobody uses."
Most of the hate comes from the overly complicated "enterprise design patterns" crap that took over the ecosystem in the late 90s into the 2000s, not the language itself. It's quite possible to write clean, clear, appropriately complex, well performing Java code.
On the plus side, of all the languages I've used Java is one of the absolute best when it comes to long term maintainability of code. This is why it's used so heavily in large enterprises with long-lived business critical code bases. Being the "COBOL of the 1990s/2000s" is not an insult, and as a language it is far superior to COBOL in every way. It's not a bad language to program in at all, while COBOL will make you hate your life.
It's also a safe language unless you break out of the JVM with JNI. It's the first safe language to get huge deployment if you don't count scripting languages. Safe doesn't mean you can't have security bugs of course, it just means you're not likely to have certain kinds of security bugs and stability problems like memory errors.
The JVM is really a fantastic piece of engineering and IMHO represents a whole direction in computing I feel sad that we didn't take. We opted to stay close to the metal with all the security, portability, code reuse, and other headaches that entails, instead of going into managed execution environments that make all kinds of compatibility and reuse and portability problems mostly go away.
The biggest current knock against Java I see is JNI, which unlike the core language is absolutely horrible. The second biggest knock is that the JVM is still kind of a memory pig. CPU performance is great, sometimes converging with C or Rust performance depending on work load, but it still hogs RAM.
> The biggest current knock against Java I see is JNI
Then you'd be happy to learn that it's been superseded by FFM: https://openjdk.org/jeps/454 (not in all situations, but in almost all).
> The second biggest knock is that the JVM is still kind of a memory pig
I would strongly recommend watching this keynote from this year's ISMM (International Symposium on Memory Management) on this very subject: https://www.youtube.com/watch?v=mLNFVNXbw7I
The long and short of it is that (and I'm oversimplifying the talk, of course) if you use less than 1GB of RAM per CPU core, then you're likely trading off CPU for RAM in a way that's detrimental, i.e. you're wasting a valuable resource (CPU) to save a resource (RAM) that you can't put to good use (because the amount of work you can do on a machine is determined by the first of these resources to be exhausted, so you should use them in the ratio they're provided by the hardware). Refcounting collectors and even manual memory management (unless you're using arenas almost exclusively) optimise for memory footprint at the expense of CPU. Put another way, the JVM takes advantage of the more plentiful RAM to save on the more costly CPU.
Sorry if this is a stupid question, but does this argument continue to make sense for desktop applications, which don't typically use much CPU unless they're currently focused, but do use the same amount of RAM regardless of whether they're focused?
> The biggest current knock against Java I see is JNI, which unlike the core language is absolutely horrible.
JNI was only ever designed to be good enough, and it is. The new FFM API aims to replace JNI in most cases, but it's designed to be "perfect". As a result, the new API took many years to develop, but JNI was quick to develop.
It would be nice to have the FFM API much sooner, but alternatives like JNR and JNA have been around for a long time. There wasn't a rush to develop a JNI replacement.
The language has evolved a lot since the "enterprise" Java days. Much of the unnecessary ceremony was relaxed, and it became less religiously adherent to the idea that it was simply a compiled, statically typed successor to Smalltalk.
...but the elders still decree Java will never be granted ergonomics QoL improvements like getters/setters because...? At this point it feels like their pride is at stake.
In my post, I’m referring to Java’s refusal to adopt “properties” (i.e. methods invoked using the same syntax used for fields) like VB, C#, JavaScript, Swift, et cetera.
I have mostly heard these complaints from people who haven't used a java ide and/or do not know that jvms allow waiting for a debugger before starting execution (helps with all sorts of spring or whatever errors and boilerplate).
That said, there is a shitload of "enterprise" fuckery in Java, but those Devs would have made a mess of any codebase anyway.
Something I've had to do a handful of times against production systems when we absolutely couldn't reproduce an issue locally. Such a great debug ecosystem.
How much experience do you have working in Java? This statement really surprises me because Java has some of the best in class tools to debug and troubleshoot issues.
This has to be one of the wrongest opinions I've ever seen on HN. It's mind-bendingly wrong.
Java would, IMO, be the easiest programming language in the world to debug. The debugging tools are mature, consistent and extensive.
In my experience, the problem of Java is the lack of standardized tooling.
To build an average Java software, you have to install a specific version of JDK, download a specific build system (Ant, Maven, Gradle, Bazel), hope everything works out on the first try - and if not, debug the most-likely-XML spec file searching for invalid dependency that's printed out on the 1000-line error output...
What Java is desperately missing is something like Python's `uv`.
---
Sibling comment mentioned that debugging Java itself is also a nightmare, which reminds me of the many Spring Boot projects I've had to debug. Stack traces containing 90% of boilerplate code layers, and annotations throwing me from one corner of the codebase to another like a ragdoll...
Admittedly, that's not inherently the problem of Java, but rather the problem of Spring. However, Spring is very likely to be found in enterprise projects.
I think this is really just anecdotal to your experience. Don’t you need to install a specific version of a compiler or interpreter for every language? Isn’t trying to build any complex project a pray on the first try? I’ve worked in Go codebases where it’s not simply “go build”. It’s: try go build, oops you need to use the make/justfile, oops don’t forget you need to install jq or some other random tool. Complex projects are complex.
Not at all? There is an obvious difference between modern languages' (Go, Rust, Zig) build systems and the old mess (C++, Java, Python). You have one tool that does everything you need, from formatting and linting to package management and building. No need to choose between Maven or Gradle or try to string together five third party programs that barely work together.
> I’ve worked in Go codebases where it’s not simply “go build”.
A rather funny statement that says the opposite of what you intended. That you can expect most Go projects to be built with just `go build` is high praise.
I expect most Java projects to be built with mvn package or gradle build. It doesn’t mean it’s always that simple. Simple projects can be built simply. Complex ones are never handled by 1 tool. There are plenty of examples in Rust and Go where people have to use make or just.
This has been one of my pet peeves on our projects; how simply can I build a project and run it. Ideally with just Java and git, can I download, build and run. Throw in some projects with native libraries, can I build with compiler tools installed but not building 5 other projects first with environment variables pointing to locations of code.
However, gradle build or mvn install won’t select a proper version of Java to build your code. It won’t even tell you are building with wrong version. Rust, Go, even Scala SBT will.
Normally you just define source and compile target and then use whatever JDK supports them. Dependency on exact version is a rare thing. Neither gradle nor Maven are independent native tools, both run on the same JVM they use, so they are not even aware of your specific OS configuration and available JDKs. But they will certainly tell you if your JDK does not support your source or compile target.
> However, gradle build or mvn install won’t select a proper version of Java to build your code.
build.gradle.kts
java {
toolchain {
languageVersion = JavaLanguageVersion.of(17)
//bonus: pick your favorite distribution with vendor = JvmVendorSpec.<X>
}
}
Oh yes they will.
> It won’t even tell you are building with wrong version.
Right, "Class file has wrong version" doesn't explicitly tell you it's the wrong JDK. Gradle itself runs from a JDK8, so even the install you made with your Windows XP will work fine.
If your last experience with Java was 20 years ago and you think that for some reason it hasn't kept up with modern advancement and leapfrogged most languages (how's async doing in rust? virtual threads still stuck nowhere? cool.), sure, keep telling yourself that. You could at least keep it to yourself out of politeness though, or at the very least check that what you're saying is accurate.
> To build an average Java software, you have to install a specific version of JDK, download a specific build system (Ant, Maven, Gradle, Bazel), hope everything works out on the first try
to build a modern java project with gradle, you need _any_ jvm installed on your pc. you execute a task via the gradle wrapper (which is committed alongside the code) and it will download and invoke the pinned version of gradle, which then downloads the configured java toolchain (version, vendor, etc.) if it can't find it on your machine.
> to build a modern java project with gradle [...] it just works.
That's the thing - it "just works" if you're on a "modern" Java project, if it uses Gradle, and if it uses it properly. Most of the Java projects I've had pleasure on working profesionally were not on that standard of quality.
You may argue that it's up to developers to keep build system simple, but in that case C++ tooling also "just works" because you can build a modern C++ project that uses CMake in two commands.
Good tooling prevents the project build process from becoming an undocumented Rube Goldberg's machine.
I disagree with this. The tooling around JVM is great or at least good enough.
Maven is mostly smooth sailing comparing to Python's env solutions or JS ecosystem. Maven is 21 years old. A quick search says Python has/had; pip, venv, pip-tools, Pipenv, Poetry, PDM, pyenv, pipx, uv, Conda, Mamba, Pixi.
Debugging is just fine. Modern debugging tools are there. There is remote debugging, (although limited) update & continue, evaluating custom expressions etc. I don't know what they complain about. If using Clojure, it is also possible to change running application completely.
Monitoring tools are also great. It is easy to gather runtime metrics for profiling or monitoring events. There are tools like Mission Control to analyse them.
Python is a front-end for C, like Perl, PHP and Ruby. Its environment configuration is a mess, specially if you need to recompile libraries with different python versions.
Java may have a long history of compatibility issues between the compiler, tooling and libraries, but it's all reasonably delimited to the Java language, so, if anything, a `nvm` equivalent such as sdkman.io should suffice.
I totally disagree, please don't add something like envs to Java, ever. Working with Python is a huge pain because of that.
Also, mostly just a JDK that is new enough, because of the strong backwards compatibility of the Java ecosystem.
Spring does some magic, but I cannot agree with you that it is hard to debug. Maybe if you don’t understand it at all, but its architecture isn’t rocket science.
I feel like that tide is changing in general. Not that two wrongs make a right, but don’t forget Microsoft once sold “Linux Licenses”, and then there’s the whole SCO vs IBM debacle. Lawyer driven revenue streams are falling out of style, unfortunately Oracle was a late bloomer. They’ve done an incredible amount of damage to their reputation.
Not everyone cares that much about their reputation outside FOSS circles.
Sun was aided by Oracle and IBM into the whole Java push during its early days.
Many apparently aren't aware of their roles into the whole Java history.
Oracle was the first RDMS with Java drivers, all GUI tooling rewriten into Java, JVM into the database, JSF famework, and acquisition of BEA and its JIT technology.
Also collaboration with Sun in the Network Computer thin client with its Java based OS.
The only thing that's paid is support, and the OpenJDK folks are Oracle employees (well, the ~90% of them who do ~95% of the work on OpenJDK). OpenJDK is an Oracle project in the same sense that Chromium is a Google project. In fact, OpenJDK (even more precisely - the OpenJDK JDK) is the name given to Oracle's implementation of the Java SE specification, but we do get contributions from other companies, such as this particular great enhancement to JFR (even external contributions also involve significant work by Oracle employees).
Anyway, if you don't want to buy a support service, either from Oracle or any of the other companies that sell it, the use of the JDK is free. There is no "enterprise" flavour of the JDK, paid features, or use restrictions as there used to be under Sun's management. Java is obviously freer now - as in beer or in speech - than it was 20 years ago.
Then why is it every time the Oracle reps come around, we are audited by our use of Java, what machines they are on, how many cores, etc as additional line items to our Oracle agreements that we have to fight, every year, to get removed? They state themselves, they charge per-employee, not per core now…
While everything you say sounds true, it’s not free - it’s gunpoint, it’s a lie, and if you’re big enough Oracle will come after you for subscription fees.
RedHat does the same crap. Heaven forbid you run RHEL on RHEL in containers, you’re gonna get fleeced.
Your company has bought support from Oracle - either for the JDK or for some other product bundle - and that's part of the terms of whatever commercial service your company bought. There are no audits and no cost for people who just download and use the JDK. Oracle doesn't collect names or contacts, you don't need to provide any when you download the JDK, and the licence expressly permits commercial use (even if you choose the non-open-source licence; the download page for the non-opensource distribution says [1]: "JDK N binaries are free to use in production and free to redistribute, at no cost"). There used to be lots of use restrictions back in the Sun days, but Oracle removed them.
> Heaven forbid you run RHEL on RHEL in containers, you’re gonna get fleeced.
You can run unlimited RHEL containers on a subscribed RHEL system. It's even set up where if you run a UBI container (a redistributable subset of RHEL content) on a subscribed RHEL system it automatically upgrades to full RHEL.
GraalVM is a separate product developed by an unrelated team. Its enterprise flavour is not considered an enterprise flavour of the JDK. The closest to an enterprise JDK from Oracle I can think of is the "Enterprise Performance Pack" for the 12-year-old Java 8, but it has nothing that isn't in the free and open recent releases (which actually include many more performance enhancements).
The idea there is that it's cheaper for companies with legacy software that isn't actively maintained to pay for some portion of the performance improvements in modern JVM generations than to ramp up maintenance to upgrade to modern Java, and this can help fund the continued evolution of OpenJDK.
what happens when the legacy code is migrated to the new java, which is supposedly easier to upgrade post java 8? who will pay for long term support if upgrading is so easy?
There's always legacy systems; it's part of the natural lifecycle of software. Also, what you buy is any kind of support, regardless of the version you're on. Support doesn't mean access to patches but an SLA for the tickets you file.
What rug pull do you picture could happen at this stage? OpenJDK is the reference spec. Fully open source. Stewarded by multiple companies. Even if Oracle somehow managed to force the whole thing closed source (not sure that's even possible?) you've got all the other contributors who'd "hell no", fork and away you go. Which version of Java do you think the community would go with? There's no way it'd work.
Maybe add those links in the posts themselves. The first one mentions what the second one will be about, you could just turn that into a link. Or have a bullet list of all the links you add to each post in the series.
I just hope with new lightweight threads I never have to write async reactive code again. It was a such an unproductive mistake, most applications do not need that level of complexity - now we can confidently say no applications need that level of added complexity.
Even for the applications that need reactive I do wonder if anyone has actually done the financial analysis between the extra developers and development time needed for reactive vs just throwing more servers at the problem.
C10k is basically just impractical without reactive / async / coroutines / that style. But with it it's extremely achievable on even midrange consumer hardware depending on the specific workload.
Nah, you could easily have much more than 10k threads on regular hardware for a long time with the traditional threads.
c10k was coined in the last millenium when a brand new PC would have 128 MB of memory and a single core 400 MHz cpu. And people were doing it with async IO, not threads back then. (Around the same time Java people got interested in Volanomark which is a similar thing but with threads - since Java didn't even have nonblocking IO then).
See eg this about 100k+ threads on Linux in 2002: https://lkml.iu.edu/hypermail/linux/kernel/0209.2/1153.html .. which mostly concerns itself with conserving memory address space since they are dealing with the 32-bit 4GB limitation of decades past.
(c10k was also about OS TCP stack limitations that were soon fixed)
C10k is pretty obsolete problem now, ten thousand threads is pretty trivial on modern machines. With modern load balancing you dont even have to worry about that problem any more. And that was before Java 25.
Modern servers yes, still has poor performance on consumer hardware even if it's technically achievable. That also disregards the kernel memory and thread contention overheads that eat into effective performance.
It's obsolete not just because of new hardware but because we got better ergonomics for these new programming styles.
That is completely different from what I’m discussing. You can have millions of virtual threads without ending up in reactive hell. Even still without virtual threads what’s more expensive 2x the dev team or a few more servers?
Depends on how many times the few more servers are duplicated. Getting an extra server for on-premises installed products is worse than pulling teeth. It’s not one server, it is one server times a thousand.
It was a better model for reasoning about concurrency, i.e. evaluate two expressions, rather than where virtual threads is headed, i.e. "you don't have to learn anything" - just spawn two threads, keep writing sequences of statements and pretend nothing's changed since the 90s.
Well, I hoped too. The problem is that "lightweight" are not that lightweight, as they need garbage collection. So, in theory, one can create 100K threads on one machine, but in practice that's going to keep burning processor for GC cycles.
Another thing is what those lightweight threads are doing? If they play with CPU that's ok, you pay GC penalty and that's all. But if they access limited resources (database, another HTTP service), etc. in real application you face the standard issue: you cannot hit the targeted system with any data you want, this external system will backfire, sooner or later.
The good thing in reactive programming is that it does not try to pretend that above problem does not exist. It forces to handle errors, to handle backpressure, as those problems will not magically disappear when we switch to green threads, lightweight threads, etc. There is no free lunch here, network has its restrictions, databases has to write do disk eventually, and so on.
> So, in theory, one can create 100K threads on one machine, but in practice that's going to keep burning processor for GC cycles.
The focus on "100k threads" and GC overhead is a red herring. The real win isn't spawning a massive number of threads, but automatically yielding on network I/O, like e.g. goroutines do. In an I/O bound web application, you'd have a single virtual thread handling the whole request, just like a goroutine does. The GC overhead caused by the virtual thread is minuscule compared to the heap allocations caused by everything else going on in the request.
If you really have a scenario for 100k virtual threads, they would not be short lived.
> But if they access limited resources (database, another HTTP service), etc. in real application you face the standard issue: you cannot hit the targeted system with any data you want
Then why would you do it? That sounds like an architectural problem, not a virtual thread problem. In an actor system, for example, you wouldn't hit the database directly from 100k different actors.
> The good thing in reactive programming is that it does not try to pretend that above problem does not exist.
This compares a high-level programming paradigm, complete with its own libraries and frameworks, to a single, low-level concurrency construct. The former is a layer of abstraction that hides complexity, while the latter is a fundamental building block that, by design, does not and cannot hide anything.
> It forces to handle errors, to handle backpressure, as those problems will not magically disappear when we switch to green threads, lightweight threads, etc.
Synchronous code handles errors in the most time-tested and understandable way there is. It is easy to reason about and easy to debug. Reactive programming requires explicit backpressure handling because its asynchronous nature creates the problem in the first place. The simplest form of "backpressure" in synchronous code with a limited amount of threads is the act of blocking. For anything more than that, there are the classic tools (blocking queues, semaphores...) or higher-level libraries built on top of them.
Yes. What I was trying to imply is that now there is a lightweight processing unit that still is able to suspend on IO (independently and without involvement from the OS scheduler), but can do that without relying on async/reactive patterns on code level. This required significant changes to the standard lib and runtime.
I never thought I would be excited for a new release of Java, but ever since Java 21, I have grown to actually enjoy writing the language. Whomever is running it has really done a good job making the language actually fun to write in the last few years.
Mark Reinhold runs it, having been there since 1.x days as the core tech lead. He also pushed the move to open source and fast release cycles. But mainly he seems to have recruited and developed good people. I can’t think of a more enduring lead facing more challenges, technical and organizational.
Yes Mark is the Chief Architect with vast responsibility, in addition is Chief Language Architect Brian Goetz [1] and the OpenJDK Amber Project members [2][3].
CPU-time would over-emphasize regions where many threads are running, right?
I find wall-time useful for finding serial regions that aren't yet parallelized.
What benefit could one possibly get by farming karma on site like hacker news. It's not like one can gather followers or something. I'm always mystified by folks who do this. Would love to understand the motivation.
Having multiple high karma accounts is useful in astroturfing, as moderators are (rightfully) more lenient on established community members than new accounts.
Same thing is widespread on reddit, usually for pushing specific products/projects/organizations into the limelight. Landing on the frontpage of reddit/HN drives huge amount of traffic, so obviously "optimizers" learned this, and started priming accounts for future vote-rings and what not, but they need to mix in real-looking content between the pushes so the accounts don't get banned.
A few days ago I flagged a piece someone else had written with ai. It has a specific cadence and some typical patterns. But many people seemed to buy it before I commented. I was surprised.
Today I pushed the boundary further and it clearly was that boundary.
Check my comment history.
I started out just saying “rephrase this so it sounds tighter” and moved recently towards just jotting rough notes and saying “make an HN comment out of this” and then editing.
I’ve been using gpt-5. I was going to see how Claude sonnet 4 performs at coming across as human-written / flagging some spidey senses.
The biggest problem with Java these days is java developers are not really good at all. I would say n the last 10 years 99 percent of "Java" devs cant competently read a stack trace.
Im not sure why anyone would improve this language when the developers are so frankly pathetic. Let them use 1.8. The ecosystem has improved. Devs have gotten worse.
Java has become a land of opportunists just trying to pass of their non-Java maybe non-programmer skills
Really curious what makes you say this. Do you see the same thing in other languages? I've worked with many great Java devs over the years and think I'm halfway decent myself after working with it for 16+ years. Are there some bad ones in between? Sure, but that's true of any language (especially javascript).
Modern tracing-moving GCs offer very efficient memory management algorithms that are often hard to beat on performance. Their price isn't so much performance anymore as memory footprint, while manual memory management (and refcounting GCs) optimise not for performance but for footprint (often at the cost of performance). Even this tradeoff is often misunderstood, as covered by this brilliant keynote from the most recent International Symposium on Memory Management: https://youtu.be/mLNFVNXbw7I
There isn't such thing, if you mean Rust, affine types systems require tree structures and have issues with multiple scopes, hence the memes with borrow checker.
Which I would refer as compiler assisted, although not really a proper term.
There is a reason outside Rust, everyone else is string to combine GC alongside affine/linear/effects/dependent types instead of one solution for everything.
The productivity of having a GC, with the type system capabilities to go lower level, when the profiler says so.
Although I have to conceded, Rust made a great job bringing ATS and Cyclone ideas into mainstream.
Additionally with AI powered languages, naturally most of this will be automated anyway.
Maybe not how you were brought up, and people argue... But Watson & Watson, back in '87, described ref counting as "An efficient garbage collection scheme for parallel computer architectures".
Even the dragon book refers to ref counting as a form of garbage collection.
Line 2 of Ref counting's Wikipedia page refers to garbage collection.
People have argued since the invention in 1960, but... Ref counting is one form of GC. [0] It might not be a tracing GC, but it is GC.
As refcounting and tracing are the two primary starting points for garbage collection, they're its two pillars so to speak (e.g. https://web.eecs.umich.edu/~weimerw/2012-4610/reading/bacon-...), I don't know of any serious person in the memory management space who doesn't see refcounting as a GC, although some languages with a refcounting GC say "they don't have a GC" in their marketing material.
As a general rule, tracing seeks to optimise for throughput while refcounting seeks to optimise for footprint, although the two can become more elaborate and converge (as shown in the paper I linked).
The JVMin in the last 6-8 years has been a powerhouse of innovation and cool features. Incredibly impressive!
And a thank you to Oracle for being a good steward of the language.
I really don't want to upvote this sentiment but I must anyway.
The fact is, despite Oracle being a menace to the tech industry, Java under their watch is thriving. Which is weird, because I don't know anyone who gives them money for Java. I'm genuinely curious who these companies are and what their incentives are!
For real. When Sun got bought, I thought to myself: “At least they would also destroy Java…”.
But nooo, Java thrives and flourish under Oracle protection.
Java gets more hate than it deserves. "There are languages everyone complains about and languages nobody uses."
Most of the hate comes from the overly complicated "enterprise design patterns" crap that took over the ecosystem in the late 90s into the 2000s, not the language itself. It's quite possible to write clean, clear, appropriately complex, well performing Java code.
On the plus side, of all the languages I've used Java is one of the absolute best when it comes to long term maintainability of code. This is why it's used so heavily in large enterprises with long-lived business critical code bases. Being the "COBOL of the 1990s/2000s" is not an insult, and as a language it is far superior to COBOL in every way. It's not a bad language to program in at all, while COBOL will make you hate your life.
It's also a safe language unless you break out of the JVM with JNI. It's the first safe language to get huge deployment if you don't count scripting languages. Safe doesn't mean you can't have security bugs of course, it just means you're not likely to have certain kinds of security bugs and stability problems like memory errors.
The JVM is really a fantastic piece of engineering and IMHO represents a whole direction in computing I feel sad that we didn't take. We opted to stay close to the metal with all the security, portability, code reuse, and other headaches that entails, instead of going into managed execution environments that make all kinds of compatibility and reuse and portability problems mostly go away.
The biggest current knock against Java I see is JNI, which unlike the core language is absolutely horrible. The second biggest knock is that the JVM is still kind of a memory pig. CPU performance is great, sometimes converging with C or Rust performance depending on work load, but it still hogs RAM.
> The biggest current knock against Java I see is JNI
Then you'd be happy to learn that it's been superseded by FFM: https://openjdk.org/jeps/454 (not in all situations, but in almost all).
> The second biggest knock is that the JVM is still kind of a memory pig
I would strongly recommend watching this keynote from this year's ISMM (International Symposium on Memory Management) on this very subject: https://www.youtube.com/watch?v=mLNFVNXbw7I
The long and short of it is that (and I'm oversimplifying the talk, of course) if you use less than 1GB of RAM per CPU core, then you're likely trading off CPU for RAM in a way that's detrimental, i.e. you're wasting a valuable resource (CPU) to save a resource (RAM) that you can't put to good use (because the amount of work you can do on a machine is determined by the first of these resources to be exhausted, so you should use them in the ratio they're provided by the hardware). Refcounting collectors and even manual memory management (unless you're using arenas almost exclusively) optimise for memory footprint at the expense of CPU. Put another way, the JVM takes advantage of the more plentiful RAM to save on the more costly CPU.
Sorry if this is a stupid question, but does this argument continue to make sense for desktop applications, which don't typically use much CPU unless they're currently focused, but do use the same amount of RAM regardless of whether they're focused?
When it comes to desktop apps much of the memory is paged out to disk anyway when a program is not focused.
When is FFM going to be production ready?
Since JDK 22 https://openjdk.org/jeps/454
> The biggest current knock against Java I see is JNI, which unlike the core language is absolutely horrible.
JNI was only ever designed to be good enough, and it is. The new FFM API aims to replace JNI in most cases, but it's designed to be "perfect". As a result, the new API took many years to develop, but JNI was quick to develop.
It would be nice to have the FFM API much sooner, but alternatives like JNR and JNA have been around for a long time. There wasn't a rush to develop a JNI replacement.
The language has evolved a lot since the "enterprise" Java days. Much of the unnecessary ceremony was relaxed, and it became less religiously adherent to the idea that it was simply a compiled, statically typed successor to Smalltalk.
...but the elders still decree Java will never be granted ergonomics QoL improvements like getters/setters because...? At this point it feels like their pride is at stake.
I don't understand what you're saying. Java records don't need getters/setters. If you want that interface there's lombok.
Records is a very new addition. lombok is writing bytecode directly to facilitate that.
wut? Java has always had getters and setters
Downvoted for stating an objective fact?
(I didn’t downvote you)
In my post, I’m referring to Java’s refusal to adopt “properties” (i.e. methods invoked using the same syntax used for fields) like VB, C#, JavaScript, Swift, et cetera.
I hate Java because debugging java code is worse than debugging assembly
As a Intellij-user I am more than a little confused. What are features missing from Java's debugging story?
I have mostly heard these complaints from people who haven't used a java ide and/or do not know that jvms allow waiting for a debugger before starting execution (helps with all sorts of spring or whatever errors and boilerplate).
That said, there is a shitload of "enterprise" fuckery in Java, but those Devs would have made a mess of any codebase anyway.
Yeah this comment is wild to me. Java’s debugging is so good I can debug a remote server from my local machine.
Something I've had to do a handful of times against production systems when we absolutely couldn't reproduce an issue locally. Such a great debug ecosystem.
How much experience do you have working in Java? This statement really surprises me because Java has some of the best in class tools to debug and troubleshoot issues.
This has to be one of the wrongest opinions I've ever seen on HN. It's mind-bendingly wrong. Java would, IMO, be the easiest programming language in the world to debug. The debugging tools are mature, consistent and extensive.
This is really a wild take. Java's debugging support is one of the best out there.
I hate to say it, but this is because you are not a Java developer. It’s very easy to debug.
Found out another printf debugger.
In my experience, the problem of Java is the lack of standardized tooling.
To build an average Java software, you have to install a specific version of JDK, download a specific build system (Ant, Maven, Gradle, Bazel), hope everything works out on the first try - and if not, debug the most-likely-XML spec file searching for invalid dependency that's printed out on the 1000-line error output...
What Java is desperately missing is something like Python's `uv`.
---
Sibling comment mentioned that debugging Java itself is also a nightmare, which reminds me of the many Spring Boot projects I've had to debug. Stack traces containing 90% of boilerplate code layers, and annotations throwing me from one corner of the codebase to another like a ragdoll...
Admittedly, that's not inherently the problem of Java, but rather the problem of Spring. However, Spring is very likely to be found in enterprise projects.
I think this is really just anecdotal to your experience. Don’t you need to install a specific version of a compiler or interpreter for every language? Isn’t trying to build any complex project a pray on the first try? I’ve worked in Go codebases where it’s not simply “go build”. It’s: try go build, oops you need to use the make/justfile, oops don’t forget you need to install jq or some other random tool. Complex projects are complex.
> Isn’t trying to build any complex project a pray on the first try?
I managed to build Docker Daemon - one of the most widely used and complex Go projects - from source with a simple `go build`.
I've never figured out how to build Jenkins from source.
Do you know of any widely used Java project that has a simple build process? Maybe a positive anecdote could change my mind.
[dead]
Not at all? There is an obvious difference between modern languages' (Go, Rust, Zig) build systems and the old mess (C++, Java, Python). You have one tool that does everything you need, from formatting and linting to package management and building. No need to choose between Maven or Gradle or try to string together five third party programs that barely work together.
> I’ve worked in Go codebases where it’s not simply “go build”.
A rather funny statement that says the opposite of what you intended. That you can expect most Go projects to be built with just `go build` is high praise.
I expect most Java projects to be built with mvn package or gradle build. It doesn’t mean it’s always that simple. Simple projects can be built simply. Complex ones are never handled by 1 tool. There are plenty of examples in Rust and Go where people have to use make or just.
This has been one of my pet peeves on our projects; how simply can I build a project and run it. Ideally with just Java and git, can I download, build and run. Throw in some projects with native libraries, can I build with compiler tools installed but not building 5 other projects first with environment variables pointing to locations of code.
However, gradle build or mvn install won’t select a proper version of Java to build your code. It won’t even tell you are building with wrong version. Rust, Go, even Scala SBT will.
Normally you just define source and compile target and then use whatever JDK supports them. Dependency on exact version is a rare thing. Neither gradle nor Maven are independent native tools, both run on the same JVM they use, so they are not even aware of your specific OS configuration and available JDKs. But they will certainly tell you if your JDK does not support your source or compile target.
> However, gradle build or mvn install won’t select a proper version of Java to build your code.
Oh yes they will.> It won’t even tell you are building with wrong version.
Right, "Class file has wrong version" doesn't explicitly tell you it's the wrong JDK. Gradle itself runs from a JDK8, so even the install you made with your Windows XP will work fine.
If your last experience with Java was 20 years ago and you think that for some reason it hasn't kept up with modern advancement and leapfrogged most languages (how's async doing in rust? virtual threads still stuck nowhere? cool.), sure, keep telling yourself that. You could at least keep it to yourself out of politeness though, or at the very least check that what you're saying is accurate.
> To build an average Java software, you have to install a specific version of JDK, download a specific build system (Ant, Maven, Gradle, Bazel), hope everything works out on the first try
to build a modern java project with gradle, you need _any_ jvm installed on your pc. you execute a task via the gradle wrapper (which is committed alongside the code) and it will download and invoke the pinned version of gradle, which then downloads the configured java toolchain (version, vendor, etc.) if it can't find it on your machine.
it just works.
> to build a modern java project with gradle [...] it just works.
That's the thing - it "just works" if you're on a "modern" Java project, if it uses Gradle, and if it uses it properly. Most of the Java projects I've had pleasure on working profesionally were not on that standard of quality.
You may argue that it's up to developers to keep build system simple, but in that case C++ tooling also "just works" because you can build a modern C++ project that uses CMake in two commands.
Good tooling prevents the project build process from becoming an undocumented Rube Goldberg's machine.
[dead]
I disagree with this. The tooling around JVM is great or at least good enough.
Maven is mostly smooth sailing comparing to Python's env solutions or JS ecosystem. Maven is 21 years old. A quick search says Python has/had; pip, venv, pip-tools, Pipenv, Poetry, PDM, pyenv, pipx, uv, Conda, Mamba, Pixi.
Debugging is just fine. Modern debugging tools are there. There is remote debugging, (although limited) update & continue, evaluating custom expressions etc. I don't know what they complain about. If using Clojure, it is also possible to change running application completely.
Monitoring tools are also great. It is easy to gather runtime metrics for profiling or monitoring events. There are tools like Mission Control to analyse them.
Python is a front-end for C, like Perl, PHP and Ruby. Its environment configuration is a mess, specially if you need to recompile libraries with different python versions.
Java may have a long history of compatibility issues between the compiler, tooling and libraries, but it's all reasonably delimited to the Java language, so, if anything, a `nvm` equivalent such as sdkman.io should suffice.
> What Java is desperately missing is something like Python's `uv`.
JBang exist and (if I'm not mistaken) predates uv. See jbang.dev
We don't need Rust written tools in Java.
I totally disagree, please don't add something like envs to Java, ever. Working with Python is a huge pain because of that. Also, mostly just a JDK that is new enough, because of the strong backwards compatibility of the Java ecosystem.
Spring does some magic, but I cannot agree with you that it is hard to debug. Maybe if you don’t understand it at all, but its architecture isn’t rocket science.
The idea that Oracle is evil and that's why they're striving to increase Java market share is the funniest thing I've read today. Thank you.
I feel like that tide is changing in general. Not that two wrongs make a right, but don’t forget Microsoft once sold “Linux Licenses”, and then there’s the whole SCO vs IBM debacle. Lawyer driven revenue streams are falling out of style, unfortunately Oracle was a late bloomer. They’ve done an incredible amount of damage to their reputation.
Not everyone cares that much about their reputation outside FOSS circles.
Sun was aided by Oracle and IBM into the whole Java push during its early days.
Many apparently aren't aware of their roles into the whole Java history.
Oracle was the first RDMS with Java drivers, all GUI tooling rewriten into Java, JVM into the database, JSF famework, and acquisition of BEA and its JIT technology.
Also collaboration with Sun in the Network Computer thin client with its Java based OS.
And a thank you to all the other amazing companies. The work on the JEP is chiefly sponsored by SAP (with help from Datadog and Amazon).
Thank You for giving credit where credit is due, especially on Oracle.
The pendulum is shifting on HN. We can finally give credit to Oracle and Facebook.
[flagged]
The only thing that's paid is support, and the OpenJDK folks are Oracle employees (well, the ~90% of them who do ~95% of the work on OpenJDK). OpenJDK is an Oracle project in the same sense that Chromium is a Google project. In fact, OpenJDK (even more precisely - the OpenJDK JDK) is the name given to Oracle's implementation of the Java SE specification, but we do get contributions from other companies, such as this particular great enhancement to JFR (even external contributions also involve significant work by Oracle employees).
Anyway, if you don't want to buy a support service, either from Oracle or any of the other companies that sell it, the use of the JDK is free. There is no "enterprise" flavour of the JDK, paid features, or use restrictions as there used to be under Sun's management. Java is obviously freer now - as in beer or in speech - than it was 20 years ago.
Then why is it every time the Oracle reps come around, we are audited by our use of Java, what machines they are on, how many cores, etc as additional line items to our Oracle agreements that we have to fight, every year, to get removed? They state themselves, they charge per-employee, not per core now…
While everything you say sounds true, it’s not free - it’s gunpoint, it’s a lie, and if you’re big enough Oracle will come after you for subscription fees.
RedHat does the same crap. Heaven forbid you run RHEL on RHEL in containers, you’re gonna get fleeced.
Your company has bought support from Oracle - either for the JDK or for some other product bundle - and that's part of the terms of whatever commercial service your company bought. There are no audits and no cost for people who just download and use the JDK. Oracle doesn't collect names or contacts, you don't need to provide any when you download the JDK, and the licence expressly permits commercial use (even if you choose the non-open-source licence; the download page for the non-opensource distribution says [1]: "JDK N binaries are free to use in production and free to redistribute, at no cost"). There used to be lots of use restrictions back in the Sun days, but Oracle removed them.
[1]: https://www.oracle.com/java/technologies/downloads/
> Heaven forbid you run RHEL on RHEL in containers, you’re gonna get fleeced.
You can run unlimited RHEL containers on a subscribed RHEL system. It's even set up where if you run a UBI container (a redistributable subset of RHEL content) on a subscribed RHEL system it automatically upgrades to full RHEL.
There is an enterprise flavor of the JDK. It's called GraalVM enterprise edition.
That has nothing to do with OpenJDK, GraalVM is its own thing.
You’re the only one who put “Open” in there. Both your parent and grandparent said JDK.
GraalVM is a separate product developed by an unrelated team. Its enterprise flavour is not considered an enterprise flavour of the JDK. The closest to an enterprise JDK from Oracle I can think of is the "Enterprise Performance Pack" for the 12-year-old Java 8, but it has nothing that isn't in the free and open recent releases (which actually include many more performance enhancements).
The idea there is that it's cheaper for companies with legacy software that isn't actively maintained to pay for some portion of the performance improvements in modern JVM generations than to ramp up maintenance to upgrade to modern Java, and this can help fund the continued evolution of OpenJDK.
what happens when the legacy code is migrated to the new java, which is supposedly easier to upgrade post java 8? who will pay for long term support if upgrading is so easy?
There's always legacy systems; it's part of the natural lifecycle of software. Also, what you buy is any kind of support, regardless of the version you're on. Support doesn't mean access to patches but an SLA for the tickets you file.
Because people keep forgetting Java is like C and C++, there are plenty of JDKs to chose from, and not all of them are related to the same codebase.
Zulu from Azul might be one? I think it comes with a difference JIT and GC in the enterprise version.
They have their own falcon jit and C4 low latency GC. I’d be interested how their GC compares to generational ZGC now.
OpenJDK is the specification implementation. A huge amount of the OpenJDK development is paid for by Oracle (And others).
Because they have a financial interest in rug pulls.
What rug pull do you picture could happen at this stage? OpenJDK is the reference spec. Fully open source. Stewarded by multiple companies. Even if Oracle somehow managed to force the whole thing closed source (not sure that's even possible?) you've got all the other contributors who'd "hell no", fork and away you go. Which version of Java do you think the community would go with? There's no way it'd work.
Why do you think a good steward shouldn't have a financial interest?
Nope, people keep forgetting no one wanted to buy Sun, not even Google after torpedoing it (which would save them from their J++ like lawsuit).
IBM kind of thought of it, but ended up withdrawing the offer.
So the anti-Oracle folks would have seen Java wither and die in version 6, and the MaximeVM technology would never had been released as GraalVM.
`sdk install java 21.0.8.fx-librca`
No pre-core fee needed.
(author here) This is part of a series of blog post. The next blog posts are: https://mostlynerdless.de/blog/2025/07/30/java-25s-new-cpu-t... (on the implementation) https://mostlynerdless.de/blog/2025/08/25/java-25s-new-cpu-t... (on sizing the queue) and a fourth on improving the performance: https://mostlynerdless.de/blog/2025/09/01/java-25s-new-cpu-t...
Maybe add those links in the posts themselves. The first one mentions what the second one will be about, you could just turn that into a link. Or have a bullet list of all the links you add to each post in the series.
Thanks for the recommendation.
I just hope with new lightweight threads I never have to write async reactive code again. It was a such an unproductive mistake, most applications do not need that level of complexity - now we can confidently say no applications need that level of added complexity.
Even for the applications that need reactive I do wonder if anyone has actually done the financial analysis between the extra developers and development time needed for reactive vs just throwing more servers at the problem.
C10k is basically just impractical without reactive / async / coroutines / that style. But with it it's extremely achievable on even midrange consumer hardware depending on the specific workload.
Nah, you could easily have much more than 10k threads on regular hardware for a long time with the traditional threads.
c10k was coined in the last millenium when a brand new PC would have 128 MB of memory and a single core 400 MHz cpu. And people were doing it with async IO, not threads back then. (Around the same time Java people got interested in Volanomark which is a similar thing but with threads - since Java didn't even have nonblocking IO then).
See eg this about 100k+ threads on Linux in 2002: https://lkml.iu.edu/hypermail/linux/kernel/0209.2/1153.html .. which mostly concerns itself with conserving memory address space since they are dealing with the 32-bit 4GB limitation of decades past.
(c10k was also about OS TCP stack limitations that were soon fixed)
C10k is pretty obsolete problem now, ten thousand threads is pretty trivial on modern machines. With modern load balancing you dont even have to worry about that problem any more. And that was before Java 25.
Modern servers yes, still has poor performance on consumer hardware even if it's technically achievable. That also disregards the kernel memory and thread contention overheads that eat into effective performance.
It's obsolete not just because of new hardware but because we got better ergonomics for these new programming styles.
That is completely different from what I’m discussing. You can have millions of virtual threads without ending up in reactive hell. Even still without virtual threads what’s more expensive 2x the dev team or a few more servers?
Depends on how many times the few more servers are duplicated. Getting an extra server for on-premises installed products is worse than pulling teeth. It’s not one server, it is one server times a thousand.
I can assure you the differences between virtual threads and reactive is not a thousand.
It was a better model for reasoning about concurrency, i.e. evaluate two expressions, rather than where virtual threads is headed, i.e. "you don't have to learn anything" - just spawn two threads, keep writing sequences of statements and pretend nothing's changed since the 90s.
https://www2.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-...
Well, I hoped too. The problem is that "lightweight" are not that lightweight, as they need garbage collection. So, in theory, one can create 100K threads on one machine, but in practice that's going to keep burning processor for GC cycles.
Another thing is what those lightweight threads are doing? If they play with CPU that's ok, you pay GC penalty and that's all. But if they access limited resources (database, another HTTP service), etc. in real application you face the standard issue: you cannot hit the targeted system with any data you want, this external system will backfire, sooner or later.
The good thing in reactive programming is that it does not try to pretend that above problem does not exist. It forces to handle errors, to handle backpressure, as those problems will not magically disappear when we switch to green threads, lightweight threads, etc. There is no free lunch here, network has its restrictions, databases has to write do disk eventually, and so on.
> So, in theory, one can create 100K threads on one machine, but in practice that's going to keep burning processor for GC cycles.
The focus on "100k threads" and GC overhead is a red herring. The real win isn't spawning a massive number of threads, but automatically yielding on network I/O, like e.g. goroutines do. In an I/O bound web application, you'd have a single virtual thread handling the whole request, just like a goroutine does. The GC overhead caused by the virtual thread is minuscule compared to the heap allocations caused by everything else going on in the request. If you really have a scenario for 100k virtual threads, they would not be short lived.
> But if they access limited resources (database, another HTTP service), etc. in real application you face the standard issue: you cannot hit the targeted system with any data you want
Then why would you do it? That sounds like an architectural problem, not a virtual thread problem. In an actor system, for example, you wouldn't hit the database directly from 100k different actors.
> The good thing in reactive programming is that it does not try to pretend that above problem does not exist.
This compares a high-level programming paradigm, complete with its own libraries and frameworks, to a single, low-level concurrency construct. The former is a layer of abstraction that hides complexity, while the latter is a fundamental building block that, by design, does not and cannot hide anything.
> It forces to handle errors, to handle backpressure, as those problems will not magically disappear when we switch to green threads, lightweight threads, etc.
Synchronous code handles errors in the most time-tested and understandable way there is. It is easy to reason about and easy to debug. Reactive programming requires explicit backpressure handling because its asynchronous nature creates the problem in the first place. The simplest form of "backpressure" in synchronous code with a limited amount of threads is the act of blocking. For anything more than that, there are the classic tools (blocking queues, semaphores...) or higher-level libraries built on top of them.
> The real win isn't spawning a massive number of threads, but automatically yielding on network I/O
This is of course what normal OS threads do as well, they get suspended when blocking on IO. Which is why 100k OS threads doing IO works fine too.
Yes. What I was trying to imply is that now there is a lightweight processing unit that still is able to suspend on IO (independently and without involvement from the OS scheduler), but can do that without relying on async/reactive patterns on code level. This required significant changes to the standard lib and runtime.
I never thought I would be excited for a new release of Java, but ever since Java 21, I have grown to actually enjoy writing the language. Whomever is running it has really done a good job making the language actually fun to write in the last few years.
Mark Reinhold runs it, having been there since 1.x days as the core tech lead. He also pushed the move to open source and fast release cycles. But mainly he seems to have recruited and developed good people. I can’t think of a more enduring lead facing more challenges, technical and organizational.
Yes Mark is the Chief Architect with vast responsibility, in addition is Chief Language Architect Brian Goetz [1] and the OpenJDK Amber Project members [2][3].
[1] https://inside.java/u/BrianGoetz/
[2] https://openjdk.org/census#amber
[3] https://openjdk.org/projects/amber/
The more I search for a new language to learn the more I want to go back to Java. I feel so nostalgic :)
I have repeatedly said this in multiple occasions: You start to really appreciate Java after you work with other languages.
Especially after you inherit a few huge JS or Python projects...
CPU-time would over-emphasize regions where many threads are running, right? I find wall-time useful for finding serial regions that aren't yet parallelized.
More detail here: https://github.com/dvyukov/perf-load. We recently implemented the same idea without requiring context-switch events: https://github.com/google/highway/blob/master/hwy/profiler.h...
This is built on a Linux sampling API that offers more accuracy, but it is still sampling.
For CPU tracing, with no sampling errors, use Apple’s M4 with the latest Xcode’s Instruments.
(author here)
Xcode doesn't know about Java's internals, so it doesn't know about Java frames, although it can help with native traces.
[dead]
[flagged]
ChatGPT
Thank you for telling, I went through their comments and they all like this :-( While having substance very obviously AI generated
someone should write an LLM detector bot that just leaves this comment on all AI slop
what?
I believe they are saying that the commenter looks a lot like karma farming with an llm, it leaves a lot of comments like this one
What benefit could one possibly get by farming karma on site like hacker news. It's not like one can gather followers or something. I'm always mystified by folks who do this. Would love to understand the motivation.
Having multiple high karma accounts is useful in astroturfing, as moderators are (rightfully) more lenient on established community members than new accounts.
Same thing is widespread on reddit, usually for pushing specific products/projects/organizations into the limelight. Landing on the frontpage of reddit/HN drives huge amount of traffic, so obviously "optimizers" learned this, and started priming accounts for future vote-rings and what not, but they need to mix in real-looking content between the pushes so the accounts don't get banned.
Yes, it is. Sort of.
I’m running an experiment.
A few days ago I flagged a piece someone else had written with ai. It has a specific cadence and some typical patterns. But many people seemed to buy it before I commented. I was surprised.
Today I pushed the boundary further and it clearly was that boundary.
Check my comment history.
I started out just saying “rephrase this so it sounds tighter” and moved recently towards just jotting rough notes and saying “make an HN comment out of this” and then editing.
I’ve been using gpt-5. I was going to see how Claude sonnet 4 performs at coming across as human-written / flagging some spidey senses.
(This was all by hand.)
I personally find this to be completely unacceptable. No one comes here to discuss with AI. Please don’t do this.
The biggest problem with Java these days is java developers are not really good at all. I would say n the last 10 years 99 percent of "Java" devs cant competently read a stack trace.
Im not sure why anyone would improve this language when the developers are so frankly pathetic. Let them use 1.8. The ecosystem has improved. Devs have gotten worse.
Java has become a land of opportunists just trying to pass of their non-Java maybe non-programmer skills
Really curious what makes you say this. Do you see the same thing in other languages? I've worked with many great Java devs over the years and think I'm halfway decent myself after working with it for 16+ years. Are there some bad ones in between? Sure, but that's true of any language (especially javascript).
If you care about performance at that level, you should not be using Java or any other language with a GC.
Modern tracing-moving GCs offer very efficient memory management algorithms that are often hard to beat on performance. Their price isn't so much performance anymore as memory footprint, while manual memory management (and refcounting GCs) optimise not for performance but for footprint (often at the cost of performance). Even this tradeoff is often misunderstood, as covered by this brilliant keynote from the most recent International Symposium on Memory Management: https://youtu.be/mLNFVNXbw7I
In my opinion this is a very outdated opinion.
Thankfully not everyone agrees.
https://www.ptc.com/en/products/developer-tools/perc
We have already have had enough from anti-GC cargo cult from "manual memory management is great" folks.
Having a GC (which RC is also an algorithm subset), doesn't preclude having other features.
Are there any public benchmarks for Perc? Or any hints as to what's going on inside?
There is also non manual, non GCed manual management.
I agree that a GC can be a viable implementation of memory management though.
There isn't such thing, if you mean Rust, affine types systems require tree structures and have issues with multiple scopes, hence the memes with borrow checker.
Which I would refer as compiler assisted, although not really a proper term.
There is a reason outside Rust, everyone else is string to combine GC alongside affine/linear/effects/dependent types instead of one solution for everything.
The productivity of having a GC, with the type system capabilities to go lower level, when the profiler says so.
Although I have to conceded, Rust made a great job bringing ATS and Cyclone ideas into mainstream.
Additionally with AI powered languages, naturally most of this will be automated anyway.
Ref counting is also no GC by the definition of a GC I was brought up with.
But yes, I was also thinking about the borrow checker.
Not necessarily in Rust, as other languages start to adopt similar techniques.
Maybe not how you were brought up, and people argue... But Watson & Watson, back in '87, described ref counting as "An efficient garbage collection scheme for parallel computer architectures".
Even the dragon book refers to ref counting as a form of garbage collection.
Line 2 of Ref counting's Wikipedia page refers to garbage collection.
People have argued since the invention in 1960, but... Ref counting is one form of GC. [0] It might not be a tracing GC, but it is GC.
[0] https://dl.acm.org/doi/10.1145/367487.367501
As refcounting and tracing are the two primary starting points for garbage collection, they're its two pillars so to speak (e.g. https://web.eecs.umich.edu/~weimerw/2012-4610/reading/bacon-...), I don't know of any serious person in the memory management space who doesn't see refcounting as a GC, although some languages with a refcounting GC say "they don't have a GC" in their marketing material.
As a general rule, tracing seeks to optimise for throughput while refcounting seeks to optimise for footprint, although the two can become more elaborate and converge (as shown in the paper I linked).
Then somehow someone has taught you badly, any proper CS reference book in academia has it, like the famous GC Handbook,
https://gchandbook.org/
The other languages adopting such type systems, also keep automatic resource management around for productivity.
The ones that don't, are still in the looking for meaningful adoption stage.
Most academic definitions of garbage collection include reference counting. It’s just a form of it.
https://gchandbook.org/contents.html
There are ways to mitigate this, the fly weight pattern, etc.