r/java • u/Sad_Importance_1585 • 4d ago
Java 25 (with virtual threads) for a startup
/r/Backend/comments/1xtp5rh/java_25_with_virtual_threads_for_a_startup/4
u/aoeudhtns 3d ago
Java has a ton of batteries-included frameworks/libraries/tools. Not just Micronaut/Quarkus/Spring/Helidon, but Iceberg, Spark, Ignite, and so on. It has some baggage due to its age (every language accumulates some), but perhaps I'm biased but I find it not that big of a deal to work around.
I love virtual threads. I am in the crowd who does not like async/await style systems. Virtual threads let you program async in a comfortable model that preserves debuggability. The evolving language support for Data Oriented Programming is situationally fantastic as well. Used that to write a small recursive parser in just a few hundred lines and it was nearly trivial.
The pros of Java from a startup perspective (in my eyes): big hiring pool. Battle-tested runtime that can scale diagonally (lowers chance you'll be hiring a team (or AI) to rewrite your system as you scale up). Big ecosystem of runtime frameworks, tools, libraries (although at this point TypeScript has probably surpassed it). Big ecosystem of build tools - testing, quality, formatting, coverage, and other analysis. As a dependency mechanism Maven has its warts but it is not the security nightmare that is npm; e.g. nothing executes by merely downloading a package. Future of the language looks bright, it is continuously being updated to work better in modern contexts (heap auto-sizing for containerized envs, Valhalla, DOP, foreign memory, Babylon, structured concurrency, and more) and not just stuck in its legacy groove. You can still do things in Java that other stacks get you, albeit with probably some more friction (for example, compiling to WASM and running on the edge. See TeaVM.)
The cons of Java: not currently "trendy." Unless you optimize startup, either with native builds or Leyden/AOT caching techniques, it's not (in its default configuration) well suited to disposable serverless. Start, re-use, then dispose when idle -- yes. A lot of legacy content out there may push your devs learning Java into older style: mutability, inheritance, verbosity. Some devs you hire might be stuck in that groove. Java shines when you lean on improvements in the 17+ era. You can definitely do UI in Java as well -- JavaFX (and you can even make that native with Graal), WebFX, CheerpJ, Vaadin, TeaVM. Those web frameworks are all beyond the traditional form-submit-server-render that the older frameworks like Faces use. But, the labor market for UI is going to mostly be JavaScript SPAs like React/Vue.
14
u/tomwhoiscontrary 4d ago
Do your programmers already know and tolerate Java?
If yes, it's an excellent choice. Modern language, world-class tooling, excellent performance.
If not, it's a disastrous choice, everyone will quit.
17
2
u/davidalayachew 3d ago
Yeah, it's an excellent choice -- Especially in the age of LLM's.
Since there is very little context to keep in mind/memory (compared to a mature codebase with millions of lines of code), the LLM is actually well-positioned to give you useful advice. Plus, they keep the LLM's relatively up-to-date, so you can even get useful info on the more modern Java. Last I checked, the LLM's are roughly 1-2 versions behind the latest Java release.
1
u/RadioHonest85 2d ago
It's a great choice if you know your way around the java ecosystem and want to work with other people that do. But for complete outsiders, maven or gradle and all the weird build and runtime things is probably not worth it in 2026
1
u/New-Departure-5969 2d ago
perf side is good. pinning mostly went away in 25 like torutofu said, what actually catches people now is the thread limit stops protecting you. with tomcat's default 200 threads, at most 200 requests could ever be stuck waiting on hikari, kind of by accident. flip spring.threads.virtual.enabled on and a few thousand can queue there at once for its 10 default connections, so they sit waiting and start hitting the 30s connection timeout instead.
dont fix that by pooling the vts, theyre meant to be cheap and thrown away. size the connection pool for what the db can actually take, and if theres a slow downstream api wrap those calls in a Semaphore with however many permits it can handle. for a greenfield app thats the main thing to think about, the rest mostly just works
16
u/Torutofu_Raeva 3d ago
honestly the dev experience is great now, and 25 fixed most of the synchronized pinning stuff so virtual threads are way less scary than they were on 21