| ▲ | Horffupolde an hour ago |
| Serious question: when should one use Java for greenfield projects in 2026? |
|
| ▲ | rwyinuse 7 minutes ago | parent | next [-] |
| 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. |
|
| ▲ | t0mas88 an hour ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | BoppreH 29 minutes ago | parent [-] | | > there is nearly no magic I agree with the rest, but there's definitely a lot of magic in Java. This is from both what features the languages makes available (many) and how the community uses them (often). I've had so many hard-to-debug issues in Java over the years due to reflection, annotations, and bytecode manipulation shenanigans. And another positive point for Java: checked exceptions. It's verbose, but knowing exactly in which ways a function can fail is extremely helpful for building robust applications. | | |
| ▲ | msluyter 18 minutes ago | parent | next [-] | | I haven't really been in the java space for a while now, but I recall there being a fair bit of criticism[1][2] of checked exceptions over the years. [1] https://www.javacodegeeks.com/2026/01/javas-checked-exceptio... [2] https://reflectoring.io/do-not-use-checked-exceptions/ WRT magic, I've generally thought that was a result of frameworks - Spring, for example. In the past, my feeling was that these impose a sort of meta/configuration language that itself is not checkable at compile time, so you'd get weird runtime errors that are somewhat inexplicable. This was like... 2018 though, so perhaps things have improved. | | |
| ▲ | BoppreH 3 minutes ago | parent | next [-] | | I'd argue that checked exceptions are still worth it, even though all the problems pointed out do exist. And that's because it works to inform consumers of what a producer is doing. Haskell has the IO and Maybe monads; Java communicates the same information through IOException and other domain exceptions. Many times I've decided to switch from one function to another, or even an entirely new library, because the checked exceptions told me that it was doing far more than I expected, and I was not comfortable introducing those new failure modes. It's far from perfect, one still has to handle nulls and wrapped/merged exceptions, but overall I like this language feature. | |
| ▲ | voidfunc 13 minutes ago | parent | prev [-] | | Checked exceptions are controversial mostly because a lot of the core APIs use them in places where it's pointless to check, like IOException. Using them correctly can be great tho. |
| |
| ▲ | theandrewbailey 3 minutes ago | parent | prev [-] | | > but knowing exactly in which ways a function can fail is extremely helpful for building robust applications I've worked on Java apps that have failed in mysterious ways that no exception could explain. Meanwhile, the overhead of having to call out certain exceptions but not others in language syntax is a bit excessive. For example, decoding URL encoded form fields into a UTF-8 string means handling a theoretical UnsupportedEncodingException. What the fuck? How the hell can one have a JVM that doesn't support UTF-8? Why does my code have to boilerplate that will never run because there might be some broken-ass JVM out there that that doesn't support UTF-8? How did it launch a web server, safely load all the libraries, and accept a web request, and route it to my code without blowing up? |
|
|
|
| ▲ | marginalia_nu 36 minutes ago | parent | prev | next [-] |
| 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. |
| |
|
| ▲ | eranation 3 minutes ago | parent | prev | next [-] |
| I wrote about it 13 years ago, some of it still stands true. https://news.ycombinator.com/item?id=5857495 |
|
| ▲ | dorkypunk an hour ago | parent | prev | next [-] |
| 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. |
|
| ▲ | topbanana an hour ago | parent | prev | next [-] |
| 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. |
|
| ▲ | skeletal88 23 minutes ago | parent | prev | next [-] |
| 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. |
|
| ▲ | foolfoolz 32 minutes ago | parent | prev | next [-] |
| 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 |
|
| ▲ | kllrnohj an hour ago | parent | prev | next [-] |
| When you think a garbage collected language is a good fit for whatever you're building? |
| |
| ▲ | kfir an hour ago | parent [-] | | Wouldn't you go with golang in that case? | | |
| ▲ | ndriscoll 40 minutes ago | parent | next [-] | | Golang gives you none of nice features of a modern language while being about the same performance tier as Scala or Java, so there's basically no reason not to use Scala. | | |
| ▲ | Thaxll 28 minutes ago | parent | next [-] | | Golang is faster and use way less memory than Java, never wonder why you never see Kubernetes controller / sidecar is Java? As for Scala it's pretty much a dead language, no one work with it and it's impossible to find dev for it. 10 years ago I was moving Scala code back to regular Java. | | |
| ▲ | weego 14 minutes ago | parent | next [-] | | It's sad - I spent a good 12 years writing Scala every day and it was the ideal language for my brain. Until it wasn't - sbt got too complex for it's own good, everything became "very smart" developers over-using implicit conversions, you couldn't find a project that wasn't an opinion war on cats vs whatever. It collapsed on the weight of it's own smugness. go and kotlin aren't it, gleam scratches the itch but I can't justify writing code that would impossible to hire for. scala situation is a real shame. | |
| ▲ | 21 minutes ago | parent | prev [-] | | [deleted] |
| |
| ▲ | eklavya 30 minutes ago | parent | prev [-] | | I ported a moderate sized java project to golang. Test suite runs order of magnitude faster now. There isn't much change in terms of the architecture. Pretty much the same algos and data structures. The whole dev tooling runs on a 16 gb mac without swapping now. I used vs code for both | | |
| ▲ | ndriscoll 14 minutes ago | parent [-] | | IME they're both in a place where Rust is maybe ~40% faster for a decent CRUD web application server, but with go you need to write much lower level code to get there (e.g. using composable generic iterators will ruin your allocations, so it's all manual for loops). You can write idiomatic high level Scala and get the same performance. Which could be as simple as the go compiler offers no ability to force inlining and has way too low of a complexity threshold, but that basically makes reusable code unusable in high performance situations. The whole go team's philosophy tends to also revolve around assuming their users don't know what they're doing, which is annoying. Like an inline keyword: thinking you know better than me doesn't mean I'm not going to inline it; it means I'm going to manually write it inline myself in the code, and then think the language sucks because it's tedious, error-prone, and verbose. Or they tend to mark lots of stuff private for no reason, and e.g. with TLS 1.3 they just ignore your config because they think they know better, etc. |
|
| |
| ▲ | topbanana an hour ago | parent | prev [-] | | I would, or C# |
|
|
|
| ▲ | orangesilk an hour ago | parent | prev | next [-] |
| Jruby is nice - runs Ruby on a Java Virtual Machine with full concurrency and Ahead Of Time compilation |
|
| ▲ | 44 minutes ago | parent | prev | next [-] |
| [deleted] |
|
| ▲ | soco 30 minutes ago | parent | prev [-] |
| 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. |
| |
| ▲ | marcosdumay 2 minutes ago | parent [-] | | Java's ecosystem is lingering since Oracle brought the language, and it's at the point where you should really look if the things you want to use are still in the state of the art, or if they felt behind every other language. And if you are starting from scratch, whatever part of the ecosystem you use, I'm not optimist on its situation improving with time. |
|