Comment by dzonga

> We now know that we prefer composition over inheritance

When people say "composition over inheritance" in Java discussions, they usually mean the trivial modeling rule: prefer has-a over is-a.

But that’s not what composition is really about.

The deeper idea is interface composition -- building types by composing multiple behavioral contracts behind a single cohesive surface.

Java provides inheritance and interfaces, but it doesn’t provide first-class delegation or traits. So most developers never really practice interface composition. They either subclass, or they wire objects together and expose the wiring.

The slogan survived. The concept mostly didn’t.

The manifold project, for example, experiments with language-level delegation to make interface composition practical with Java.

https://github.com/manifold-systems/manifold/blob/master/man...

> FactoryFactory has gone mostly extinct

it really depends on your project, and what framework(s) and libraries you choose to use.

Java still has a tonne of legacy projects using old(er) frameworks that rely on such patterns - spring has some old versions which is like that, and i am certain plenty of java projects are retaining those old versions due to lack of desire to upgrade.

If you're starting a greenfield development in java, you surely would not befall into that factoryfactory pattern (unless you're just copy/pasting old projects around...). But i imagine there's way fewer greenfield projects compared to older projects requiring maintenance.

It's still going to be hard to overcome the stigma of ex-Java developers coming into other languages and bringing their overly complex ideas with them. But I am happy to hear Java itself is evolving and I hope that limits the downstream effects of it being one of the most popular language a lot of devs start on.

If someone reads this and wonders what JBoss is, the contemporary variety is called WildFly and it is actually rather easy to install and play around with.

https://www.wildfly.org/

I think this is an often overlooked solution to some of the problems we nowadays tend to approach the clown for.

As for build systems, Maven is old and cranky but if something else replaces it, it will probably be quite similar anyway.

I'd like to mention the web framework I'm using these days, Jooby:

https://jooby.io/

I've found it quite satisfying compared to the other "new" ones.

As for the original topic, I just want to echo what others have said, and say that I am happiest in Java when writing it as if it were Golang code. That an the first-class runtime and performance and deep ecosystem make it a great choice in 2026.

Quarkus is better, but isn’t that amazing IMO.

It’s still very much an annotation festival in the code, making the framework quite lengthy to learn for newcomers (gotta learn Java and the whole quarkus annotation DSL with it).

Go is verbose, but it is much more explicit and only uses standard language things instead of a whole annotation DSL.

There's also Javalin for oneshot java projects where you write your webserver like you'd write express.js

Not sure if I agree about the Go build system. Causes me endless issues at work - and my workmates, going by the number of complaints

A friend and former colleague was agog about Quarkus and it does look pretty compelling.

Having used micronaut for a few years now, I hate it.

Maybe it's innate to trying to use a a fully fledged server-style framework in a serverless context, but I don't think it's suitable. In fact I think the whole idea ("Hey, let's bludgeon spring-like metaphors into an entirely new setting") was a poor one.

Java itself I've enjoyed more and more over time as the language has evolved into something much more expressive, and without all the enterprise crap. My hope is that one day frameworks like Micronaut will end up discarded too.

I never want to read another Bean or log4j config ever again.

> a better build system is sorely needed - one of the things that Go / Rust did right

Honestly there are only two reasons I wouldn't pick up Java for personal projects, difficult to build single executable (Graal is still very un-ergonomic), ridiculous build systems.

I can kind of live with former, but Gradle is so very extraordinarily terrible that I don't know where to begin. Problem is, it solves some real problems (in extremely bad way) that people keep using it.

I long of a cargo-style revolution in Java world. (No, the newly popped up alternatives haven't really cut it so far)

I also like Kotlin. The readability is awesome. ;)

  inline fun <reified T> Any?.cryptic() = (this as? T)?.let { it::class.simpleName?.also(::println) } ?: Unit

I must say I prefer C# over Java. They're pretty similar in a lot of ways, but LINQ is much nicer to use than the Java streaming equivalents. And there are some odd warts like Java lacking unsigned types.

> I will never invest even 5 minutes in learning that horrible Spring framework

well there's your problem - why are you using spring for a personal project, when there's so many other simpler, lighter weight frameworks around?

> Spring framework when stuff like Django, Rails, or the Go ecosystem exist.

Django and Rails have a very similar model to Spring, so frankly this is just "I was lazy to learn a new tool and it must suck" kinda take. Is there a learning curve? Sure. Does it worth it? I would say for typical CRUD stuff, yeah. No matter how trivial it is you will likely end up needing something that is a single annotation away. But you may want to try quarkus over spring.

Yeah, don't use Spring. If I'm doing DI, I want compile time DI, so Micronaut or Quarkus.

> Why would anyone create a new language now?

I'm writing my own programming language right now... which is for an intensely narrow use case, I'm building a testbed for comparing floating-point implementations without messy language semantics getting in the way.

There's lots of reasons to write your own programming language, especially since if you don't care about it actually displacing existing languages.

Most of my 20 years of experience is Java. Now 3 years into a new job mostly using Python to build microservices. I feel much more productive using Python (plus uv, ruff and mypy for fast repeatable package management, linting and type checking). I see Python having a trajectory to keep improving and gaining more adoption - eg Python keeps growing in popularity https://survey.stackoverflow.co/2025/technology/. It will have real threads soon and better type checking with ty (thanks to astral who also make uv and ruff). Python gives an incredibly tight integration loop since you don’t wait on compiling. Our kotlin projects are always at least 2x slower for ci/cd builds. I like typescript, but working with it in IntelliJ is incredibly slow.

> Why would anyone create a new language now? The existing ones are "good enough", and without a body of examples for LLMs to train on, a new language has little chance getting traction.

Compiler writing can be an art form and not all art is for mass consumption.

> Java has won (alongside many other winners of course), now the AI drawbridge is being raised to stop new entrants and my pick is that Java will still be here in 50 years time, it's just no humans will be creating it.

This makes no sense to me. If AI possesses intelligence then it should have no problem learning how to use a new language. If it doesn't possess intelligence, we shouldn't be outsourcing all of our programming to it.

What advantage do old languages have that can’t be overcome or at least reduced to insignificance?

The 50-year head start in training data, runtime, and ecosystem? That may not be much, because LLMs are rapidly accelerating software development. LLMs can also generalize: take what they learned for one language and apply it to a “similar” language (and I think most modern languages are similar enough for broad effective translation: all have records/unions, objects, functions, types, control-flow, exceptions, and more). Some fairly recent languages (e.g. Rust, Swift) already have comparable runtimes and ecosystems to older ones, from human-driven development acceleration and concept generalization.

In a recent study, LLMs solved the most exercises in Elixir (https://autocodebench.github.io Table 4). Anecdotally, I’ve heard others say that LLMs code best in Rust, and (for UI) Swift. More importantly, I don’t see an older language advantage that is widening from LLM use; an older language probably is better for most use cases today, but any written code can be translated or regenerated into a newer one.

Programmers would create a new language when there is a fundamental change in hardware architecture such that the assumptions underlying the old programming languages no longer apply. Java is probably a poor choice for writing software in which most computation happens on GPUs. But I agree that someone (or something) will still be using Java to write new line-of-business applications in 50 years.

> Why would anyone create a new language now?

Same reason you'd ever create a new language — to start anew, breaking free from the shackles of backwards compatibility of the old language, having learned the lessons of the past.

The AI angle makes even less sense — surely we will want to create languages that are tailored for them.

Why would anyone play chess in 2010? The drawbridge is rapidly being raised on human competitiveness.

The vast majority of programming languages ever created never aspired to win and I don't think that's going to change now.

Not the GP, but for really large code bases, Go is missing a few features that I've noticed:

1) No immutable types. My work team is a huge user of immutable data stuctures in Java to make sure data passed around to other teams isn't changed. Go doesn't really have a good way to do this.

2) Refactoring can be really annoying (or at least really noisy) because of public/private being defined by capitalization of method/field names.

3) Error handling isn't great. I love Go's errors being just normal values, but the `error` interface is awkward when trying to figure out what kind of errors can be thrown without having in-depth knowledge of the kinds of errors that can be returned. We regularly need to make different decisions depending on the kind of error returned. Knowing which errors can be returned in Go is not defined by the method being called (only in comments).

Go can't compete with Java bc it's not in the same category as Java.

- Java is a high-level, multi-paradigm programming language

- Go is designed as a systems language to supersede C projects at Google

Now Go identifies as a general purpose language that competes with Java? It's a free country, I guess.

"industry purposes" likely equates to "enterprise software development." And that assertion is 100% correct.

Exceptions

Ya, that seems to be a misunderstanding. "Industry purposes" covers a huge range of stuff. Go is pretty good for systems programming where Java isn't really an option due to the fundamental limits imposed by garbage collection and lack of pointers. Java is pretty good for higher-level application development where occasional GC pauses are tolerable (the GC pauses are rare and fast now, but they still rule out using Java for certain purposes).

> It performs better than Go

Do you have some sources or experiences to share on this topic? I'm very curious. My experience is the complete opposite.

At my previous job there was a Java web application and running in Kubernetes (1 vCPU and 1Gi of memory) was able to deal with at most 80 requests per second, using up almost the full 1 vCPU and ~600-700MiB of memory. That was a bit disappointing, since we were supposed to support at most ~1000rps on this API, 13+ pods is a lot, and we felt "software could do better".

A reactive guru from another team told us we should use a reactive stack, so he came in and rebuilt the app using the reactive stack. Now it was doing about 120rps on one pod (about the same memory usage), which was a good improvement, but still disappointing.

One guy on the team was motivated to rewrite the API in Go as a proof of concept, and we were blown away. With the same 1 vCPU it was now able to handle 400 requests per second, while using ~100-200MiB of memory, and having approximately 20% better response times.

> builds just as fast (at least when not using some popular build tools)

I find this a little bit of a cop-out, because almost everyone is using the popular build tools. And it's quite a chore to build a full application without those popular build tools. With Go, all batteries for building are included.

> It performs better than Go > and its optimising compiler and GCs blow Go out of the water without breaking a sweat.

Well, dandy! Since the performance gap is that big, it should be trivial to get hard data backing that up. Mind linking some representative benchmarks?

Dang, I just can't wait, same resource usage for Go and Java (RAM in particular, if you would), and Java performance that "blows Go out of the water".

> and builds just as fast

Oh? But you're comparing apples to oranges.

Go builds its source into a machine code executable, all optimizations are applied at this step. This then gets directly executed by the CPU.

Java "builds" its source into bytecode. It's a trivial transformation that then needs to actually be compiled and optimized by a virtual machine at runtime before the CPU can run it.

So then, what build time does Java have when doing AOT compilation? Again, hard numbers please, thanks.

> while offering unmatched deep, low-overhead observability.

> People might think they may enjoy another language more, but the portion of people who eventually come to regret choosing Java is probably lower than that of any other language.

Very believable statements, given that you literally work on Java for Oracle :) No need to bother to make a disclaimer about that I guess. Shameless.

> and builds just as fast

Source? I'm not saying you're lying but I have never seen any Java project build as fast as Go

With SSR/HTMX/HATEOAS the amount of code executed on client side is relatively minor and does not justify the unstable JS/TS tooling and frameworks, and the security nightmare which is NPM-based supply chain.

Different tools for different purposes...which is good/right.

TypeScript is a superior programming environment for the browser, for sure. Using it on the server? Why not, if you're not trying to scale (in capacity, or functionality).

Language-agnostic serialization exists for a good reason. It's not always right, but it's almost always the right thing to do.

The biggest problem with Typescript in the modern era is that LLMs are pretty bad at it, at least as compared to some other languages that are more well suited to LLM generation. What you say may have been a boon in the olden days, but it is hard to justify now. It is difficult to avoid Typescript/Javascript in the browser, sure, but now it's just as fast to duplicate everything in another language for the backend and at least gain the advantages on that end.

What if you have a mobile app? Rest APIs? The argument doesn't work. Every backend language has ways to generate specs/types/clients from the APIs code.

> You write your frontend in JS/TS, your backend in the same language, your build tools understand it natively, and you share types between client and server.

that's an excuse imho. It's a post-facto justifying using js on the serverside because of familiarity.

I know because the exact same reason was given for GWT (google web toolkit), and that failed pretty horribly (despite it being quite good imho).

My experience has been that developers say that they’ll share types between the frontend and backend, and then in practice they just duplicate it.

> Maybe this is just a question of taste but I never could get along with Javas (or Kotlin's) tooling

Are you joking? IntelliJ is without a doubt the best dev tooling environment available.

Besides doing yourself a disservice of not using a proper IDE, what exactly makes Java not writeable in vim or the like? Like it's a pretty simple language with not much magic going on.

They trade blows, and have different philosophies (complex runtime, simpler language vs the reverse).

E.g. on the GC side Java is ahead of any other platform, especially with the low-latency ZGC garbage collector.

On the contrary, as someone that earns their bread using both ecosystems, .NET is still pretty much tied to Windows, regardless of .NET team efforts, most shops going with macOS or Linux are former Microsoft shops saving on server licenses or giving Macs to their devs.

There are many platforms where .NET doesn't have an implementation, a phone to call their own (even if ART isn't proper Java, WP is no longer around), embedded systems, including factory and military weapons deployments (PTC, Aicas, microEJ), copiers (Xerox, Ricoh), phones (Cisco),....

C# is definitly better than Java dealing with value types and low level programing, or being embraced by the game development community, however not sure if the featurities of last years is the right path, I am starting to feel I should just reach directly to C++ instead.

Java is 4th on tiobe.

Bright future for it just means it is not planning to become 40th or 400th.

(My prediction - in next ten years java will always be among top 6; new language might come to the very top and some leapfrogging game between c# and java)

Says a single guy who may have coined the term, but that's not how words work. The industry's millions of devs use it differently, so the de facto meaning is that java is an OOP language, and the original is closer to the actor model.

Most of backend development on Java is procedural with OO syntax and ability to replace something in the chain of calls with stub in tests. Spring beans are usually stateless singletons containing a few references.

Right because golang is like 2 years old and new o.O

There's so much Java development in the Bay

chasing the new shiny? or running away from the zombie?

With all due respect, I'm fairly sure that anyone using "VM" the same way as you do here really think of it as a container or what.

It's a runtime, and go also has a similar, fairly fat runtime. It's just burnt into the binary instead of being shipped separately. (Hell, even Rust has a runtime, it's just very very lean compared to languages featuring a full GC like go and java)

JFR is one of my favorite things about the JVM. Such good tooling to figure out whatever it is you are having problems with in production.

I've also used Eclipse MAT to find tricky dangling references to objects that caused memory leaks. Definitely not as polished, but extremely useful.

I wouldn't count myself as a JavaScript person at all, and usually avoid it where I can, going to some length, to make pages static, if possible. So I am not exactly in the group of people you are attacking.

However, I am afraid of the Java coder who is decorated as senior, has sway due to their position, and who will tell me, that something, that is a simple function, shall not be a simple public static "method", but must be wrapped in yet another object, which I need to instantiate, because OOP, and because obviously I don't know what I am doing, or because it doesn't fit existing "coding practices/style" or "Java style". I am afraid of the Java coder, who for years has not touched anything but Java, because their jobs didn't require anything else, because so many companies want Java. I am afraid of the one who throws around jargon like "dependency injection" all day, without ever using simple terms, or realizing what those things are looking like in another paradigm.

Lord, please save me from ever having to work with such obnoxious and uninformed, learning resistant people. This actually may be a straw man, but even one such character matching one or more of those traits, seated above at the seniority ladder will make a mess, that everyone else has to live with.

I mean, sometimes managers are uninformed and say stupid things?

You can use any of the other jdk builds from the plethora of other vendors and have zero interaction with Oracle.

I absolutely hate Oracle as a company, but they've really done a good job with Java stewardship. They actually open sourced the entire language / jdk and a lot of the tooling that used to be proprietary.

They still love to play the old Oracle tricks, so I'd rather not use any of their distributions. But the actual work that they do on the ecosystem has been a positive in my opinion.

There are more Java devs than people in my home country. Like how could you even give a single description for all of them? They all work on vastly different stuff, from low-latency trading to robotics, to regular old CRUD. Not even the CRUD part is as monotonic though as you make it out to be.

Spring Boot isn‘t bad. It‘s opinionated about configurations and dependencies. Its main advantage is that you can start shipping production-quality code very quickly, focusing on business problems rather than anything else. Vibe coding on it is more or less stable, entire apps can be built solo in a few months. And it‘s easy to do fullstack with SSR based on Thymeleaf and Htmx. It is absolutely superior to anything that exists for node stack.

And then there‘s also Micronaut, if you prefer compile-time setup to Spring.

There's a lot of programming that has nothing to do with SpringBoot - and I say this as someone who works in a backend team that uses SpringBoot for all our apps.

You're talking to specific people.

A completely different culture of Java usage can and does exist a lot of places. It is absolutely true that success creates a certain ossification of practice. But SpringBoot is not necessary, any more than Guice or any other framework-y thing.

That's weird. Back when Java 7 was a new thing, people used Spring (Boot wasn't there yet) even more to compensate for the lack of language features. Also back then most projects still used XML configuration, so you actually write more Java code in modern Spring. Because Spring Boot uses Java configuration classes by default (although you can still use XMLs if you need for some reason).

I’ve been working in Java for 12 years, my entire career. I have never worked on a Spring project.

> Nowadays you basically don't code Java, you code Spring Boot. And that has all the bad things you think when people say "Java".

Subjective experience, but largely agreed.

Vague rant that summarizes my own experience: major version updates kind of suck, even if Spring Boot is still better than regular Spring (I've gone through the XML hell, was not fun, even less so with a separate Tomcat instance that we had to deploy to, instead of an embedded one). In practice their huge effective pom.xml also leads to conflicts when your package needs something else and it feels a bit arcane to override things. There are things that have underlying technical reasons for being the way they are but seem stupid from afar - like how @Transactional doesn't work when called from within the same bean. Personally I also prefer code over convention for configuration and initialization so the whole annotation driven setup feels quite annoying and difficult to debug when things go wrong - but even the code configuration isn't always great and sometimes it feels like they have abstractions for the sake of abstractions. Spring Boot also often brings friends like MapStruct or Lombok or Mockito which add even more dynamic behavior and issues when you update JDK, alongside slow testing with JUnit and unpleasant debugging of jumping through numerous abstraction layers. You don't strictly have to, but people will.

I probably should have written down every complaint with exact details (so those could be picked apart as user error) over the years that I've been unfortunately maintaining and building shitty software with Java, but I will say this - modern Spring Boot isn't wholly horrible, it has a pretty rich ecosystem and you can do a lot of things with it, but the overall vibe I get from it ofen can be summarized with "Eww." I'd end up using it because I have to, or because it's a means to an end ("Hey, we need to build an event-driven system to integrate with a bunch of others, you have two weeks"), not because I want to.

For the sake of comparison, I believe that for plenty of the folks even Dropwizard would be worth a look: https://www.dropwizard.io/en/stable/ it is more or less like some glue around a bunch of idiomatic packages in the Java ecosystem and it's not horribly hard to integrate something that you want yourself (e.g. Dagger 2 for DI, at this point I'll take anything that does as much as possible at compile time https://dagger.dev/dev-guide/).

Or, for a more modern spin, Quarkus isn't too bad either https://quarkus.io/ or maybe Micronaut https://micronaut.io/ or perhaps Helidon https://helidon.io/ with neither of those being strong recommendations - figure out what you like for yourselves. For people that have been luckier than me, that might as well be the very same Spring Boot, just on better projects. JVM is a pretty cool piece of tech though, and so are the JetBrains IDEs with their refactoring features and nice Maven integration.