Java 26 is here (opens in new tab)

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

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.

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.

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.

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.

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.

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)

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

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?

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.

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.

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.

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.

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.

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

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

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

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.

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.

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

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.

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

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

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

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.

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)

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)

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

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.

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.

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

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.

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.

The first domino is opting for OOP. AbstractFactoryProviderBuilders are just the inevitable downstream consequence of that initial choice. No need for factories if you don't traffic in objects in the first place.

Objects. Just say no.

   var wg = sync.WaitGroup
   defer wg.wait()

   wg.Add(1)
   go func() {
      defer wg.Done()
   }

And create a separate channel to return errors from a goroutine. Definitely more work.

Don't get me wrong, I like Java and don't very much like the Go language. But Java has a lot to improve upon still.

But it does have a learning curve and you may sometimes end up having strange error messages. (As an implementation, it's basically Scala macros turning normal looking scala functions into a static task graph). It is getting better and better support for mainstream java build setups, and it's possibly the best tool for something very custom. In between the two extremes, you may or may not have a better time with Gradle/Maven.

Hard to say because I don't know how someone without Scala experience would fare with Mill. Then again, I think anything is better than Gradle. Really, anything. I even think I would do everything by hand rather than using Gradle. Also the creator of Mill is a great guy. Rest assured, if something's confusing or not working he's gonna help you out or fix it if necessary.

In terms of async, it's when you have to have a function with "async" attached to it and making it so that only other async functions can call async functions.

It ends up creating a weird circumstance where you can end up with a lot of duplicated APIs, particularly in libraries, because you are providing both async and non-async versions of functions.

[0] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

The terminology is used to talk about languages that have async and sync functions where you declare (or color) the function as either async or sync.

In these languages it's pretty common for the language to enforce a constraint that async functions can only call other async functions. Javascript / Typescript, Python are popular examples of languages with colored functions.

In this context: functions anotated with async

"Stackful coroutines" allow yielding from any arbitrary point. They're basically fibers, except with the explicit control transfer and value passing yield and resume operators; there's no hidden or implicit control transfer like with green threads. Though, some people would argue allowing any function to yield without announcing this in their type signature is tantamount to hidden control transfer. Personally, I don't see how that's different than allowing any function to call other functions, or to loop, but in any event languages are free to layer on additional typing constraints--constraints that can be tailored to the desired typing semantics, rather than dictated by implementation details.

Stackless coroutines are typically implemented as a special kind of function whose state is allocated and instantiated by the caller. In contrast, stackful coroutines are typically implemented by reifying the stack, similar to threads. The "stack" may or not be the same as the system's ABI stack.

In stackful coroutines, unless there are additional typing constraints imposed by the language for hygiene reasons, any function can typically be called as a coroutine or use yield and resume. There's no need to compile functions into special alternative forms as call frame management works the same whether invoked from a coroutine context or not.

I’m really surprised to read this. It is well-documented process. I regularly publish something there, never had problems. Why was it different for you?

That's why you need documentation to publish to Maven central, that's why your package needs to specify its license, GPG checksum etc.

Yep, it's a lot harder than publishing to Pypi or Cargo, but I'm now firmly of the opinion that it's good that it is. The gates between you and publishing a package are there for deliberate reasons.

> Perhaps you're alluding to the things you can do with JMX

Yep, specifically things like "set the logger org.foo.package.Bla to DEBUG while the app is running", without restarting and without having to add an internal HTTP endpoint to be able to accomplish that. It's just there for free, every JVM logging library and metrics library exposes itself via JMX for that same reason - ease of observability, without restarts, without custom code.

E.g., I can access Kafka client metrics via JMX anytime I like. JConsole will even give me pretty graphs.

If I want them in Prometheus, I run the app with a Java agent that takes those MBean metrics and exports them in Prometheus format on an HTTPS endpoint.

I understand you can accomplish much the same with some internal HTTP endpoints, but that presumes they exist.

If you need them, but that microservice hasn't deliberately exposed them, you need to change the code, and then make a new release, which slows down your ability to diagnose what's going on right now.

In Java, every observability library exposes itself via JMX, all you had to do as a sysop was ensure that the JMX port was open.

Also, the ability to easily observe the metrics of the VM itself via JMX so I can see what's going on with GC in a running app without having to explicitly expose that.

If you suspect a memory leak, or something that should be GC-able isn't, or that there's far too many object allocations occurring that's smashing the first gen portion of the heap and causing excessive GC pauses, the instrumentation to investigate it as your app runs is right there, it's baked into the JVM.

That's why I miss it - the JVM was built to be instrumented and observed by the people running it.

I really wish Golang and everyone else would emulate the Java approach to observable metrics as well as the Java approach to logging and packaging.

There's no shame in stealing the good ideas Java had, but no-one seems to, to my frustration.

The JDK and JVM has advanced so fast while android has been lagging. It's pretty frustrating, especially because google has been so slow to pull in changes from later java versions.

A part of me wishes that android would just dump their hokey dalvik, ART, and other BS and just use the OpenJDK or a fork of the OpenJDK with whatever special sauce they need. A lot of the project Leyden stuff lends itself nicely to maybe someday being able to run real java on android.

Edit: Apparently android is forking OpenJDK, since Android 7.

https://en.wikipedia.org/wiki/Android_Nougat

No, they didn't. Google happily used regular Java until Oracle played Oracle. Then Google stopped updating the supported Java language version and started diversifying away from Java.