logoalt Hacker News

Horffupoldeyesterday at 1:43 PM26 repliesview on HN

Serious question: when should one use Java for greenfield projects in 2026?


Replies

pronyesterday at 2:45 PM

These days, Java is mostly used in greenfield software that has to be very reliable, very performant, and last for many years. So it's often the first choice for banking, telecom, finance, government, defence, manufacturing control, logistics and shipping, media streaming, retail, hospitality, healthcare etc.. It's usually not a first pick for more exciting software, such as Python type checkers, JS bundlers, or TUI file managers.

show 4 replies
marginalia_nuyesterday at 1:59 PM

Not at all a bad choice.

It's stable to the point of boring, and there's no shortage of people who know the language and can work with it, it's got best in class tooling, decades worth of libraries almost all very mature. Most of the language's issues are from legacy code bases coded in a style that isn't really relevant to a greenfield project.

show 1 reply
t0mas88yesterday at 1:50 PM

When building boring web applications with a sizeable team that need to run for a long time. Hiring developers is easy since there are many, there is nearly no magic and the language is quite strict and type safe so it works well with a large team.

And that "team" nowadays may also consist of many AI agents. In my experience Claude Code for example works very well with a typed, slightly boring language with lots of framework and library support. Because it doesn't compile when you get something wrong, instead of getting a vague runtime issue that Claude can't always see.

show 4 replies
rwyinuseyesterday at 2:28 PM

Java & Spring is a good choice whenever you want your application to work and be maintainable 10 years from now, without having to replace the framework and half of the libraries you used. I see few good reasons to ever use something with unstable ecosystem (like Javascript with NodeJS) over Java these days.

show 2 replies
dorkypunkyesterday at 1:48 PM

When you are already familiar with it or work in a Java shop, there are better options if you are starting from scratch, but if you already have 50 guys that know Java it's a pretty big ask for all of them to switch.

show 2 replies
chasd00yesterday at 4:35 PM

It's a stable known stack. It's not hard to find Java developers and the AI Agents are probably pretty good at writing Java too. A Java backend will just sit there and do its job happily forever and you can bolt on whatever front-end you want. Spring Boot has been kind of the standard way to do Java web applications for probably a decade if not longer. It works fine has all the bells and whistles when you're ready for them and most Java developers who work on the web know Spring already.

As for an individual developer doing a side project, you should use Java if you haven't used it before to get exposure to it. It's a fundamental component of enterprise software and if you've never used it before take the time to learn something new.

mandsyesterday at 5:51 PM

Good question - am using for a greenfield AI startup in SF. Been a great decision so far: great ecosystem, bulletproof runtime, fantastic performance and new quality features arriving on a steady schedule. "Boring technology" at its finest.

At the risk of a shameless plug - blogged about it recently at https://mandeepgill.net/2026/08/31/java-for-an-ai-startup/

kllrnohjyesterday at 1:45 PM

When you think a garbage collected language is a good fit for whatever you're building?

show 1 reply
topbananayesterday at 1:49 PM

When you work at a Java shop. Kotlin is much nicer if you have to run on the JVM but aren't restricted to Java.

show 1 reply
stickfigureyesterday at 6:46 PM

Often? It's a relatively modern language with enough functional programming features to keep mid-high blub programmers happy. Yeah there's cruft; all mature languages have cruft.

Kotlin is the obvious replacement, but the tooling isn't as good and the community isn't as large. Java keeps getting better, and in ways that diverge from Kotlin - eg, virtual threads vs async/await/coloring. From the perspective of language design, I prefer Kotlin. But I keep picking Java anyway, and I don't see that changing soon.

Go is openly hostile to functional programming. Dynamic languages aren't even in the running. Rust is too low-level for line-of-business software. C# is too Microsoft. The remaining alternatives are too obscure.

nonethewiseryesterday at 2:52 PM

Here is a niche one:

When you want to make a game and support modding with pretty much zero development effort.

foolfoolzyesterday at 2:03 PM

java is a great language for server side projects. it is actively maintained, the biggest issues with it have JEPs, and it’s very friendly to AI authors

skeletal88yesterday at 2:13 PM

Same question for .net or C#

Why should anyone use it over Java? Ms is hostile towards its developers, it creates new versions of things, deprecates previous versions, uses confusing naming for newer versions.. etc.

show 4 replies
mahboiyesterday at 7:18 PM

It's decent for backends. I'd rather use JS, but there can be performance or ecosystem reasons to use Java. They fixed a lot of the gaps it had. JS used to have a big edge in async-await while Go had n-m multithreading, but now Java has the latter.

mikert89yesterday at 3:32 PM

When you’ll have tons of low skilled devs contributing to an important but boring application that will last a while

ivan_gammelyesterday at 9:16 PM

anecdotal evidence: I‘m working on a product in circular economy space at the moment (chemical trader). I chose Java because it just works and allows us to focus on business, no npm supply chain drama, no „how can I integrate my go microservice with a customer SOAP endpoint“ problem, time to hire under 2 months etc.

pie_flavoryesterday at 3:11 PM

Java-the-language blows, but Kotlin does not, and Java-the-platform is on the Pareto frontier of oldest-yet-most-usable open-source ecosystems. I prefer Rust, and the gaps where it doesn't apply, C# fits my use cases better, but Kotlin/JVM is a rock solid development platform.

show 1 reply
eranationyesterday at 2:32 PM

I wrote about it 13 years ago, some of it still stands true. https://news.ycombinator.com/item?id=5857495

pjc50yesterday at 2:45 PM

JavaFX is fairly high up for "I want to run the same UI on Mac and Windows, and I don't want it to be an Electron web app in a box".

show 1 reply
DarkNova6yesterday at 5:04 PM

Yeah. Why use a statically typed reliable language with a good ecosystem if I can also vibecode in Python.

DanielHByesterday at 3:23 PM

Java and C# seem to be the best ways of making code-first OpenAPI based servers.

C# LINQ also seem to be the best compromise between ORM and raw SQL queries, although I never used it myself.

I have been severely disappointed in all similar solutions for Go at least and I imagine Rust does not have something better given it has a smaller community-base.

Python and NodeJS have some very neat solutions for this stuff too, but both are "slow" dynamic languages. I personally dislike python with a passion and NodeJS stuff is extremely community-driven and therefor often unreliable. Prisma (NodeJS ORM) for example just did a major overhaul and is now pushing a completely different API.

If you are making boring REST API to SQL Database it seems like Java and C# are the best options.

show 1 reply
orangesilkyesterday at 1:49 PM

Jruby is nice - runs Ruby on a Java Virtual Machine with full concurrency and Ahead Of Time compilation

socoyesterday at 2:05 PM

Whoever works with, or chooses Java, is not doing it for the language itself, be it beautiful or not. Java has a huge ecosystem, from battle tested integrations to optimized images to build pipelines to whatever, so at the same you're buying access to all this world (yes, more than an environment). And of course transferable skills. I'm not saying Java is alone offering this, also not saying every feature is the best, but you can have them all, and even choose from different options.

show 2 replies
exabrialyesterday at 4:58 PM

roughly 100% of the time