Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java 27

mail.openjdk.org

Post reply on HN
Print view View original

61–70 of 423 posts

Re: Java 27

#61

Post by ndriscoll »

eklavya wrote: post #41
ndriscoll wrote: post #30

Earlier quoted context omitted.

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.

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

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.

Re: Java 27

#62

Post by voidfunc »

msluyter wrote: post #55
BoppreH wrote: post #44

Earlier quoted context omitted.

> 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 knowin…

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 o…

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.

Re: Java 27

#63

Post by rwyinuse »

throwaway91033 wrote: post #58
petilon wrote: post #36

Earlier quoted context omitted.

> Microsoft are bundling a lot more into the platform and leaving less to the community. This is a good thing. In Java everything has multiple community offerings, so before doing anything you have to evaluate the community offerings and decide which one to go with. If you go with the wrong one you may end up having to switch at some point, and that can be painful. This happens so often that most of the time spent wh…

If someone wants to create a project by assembling bits and pieces from different open source products they can, but many just go for Spring (Boot) and call it a day. All of my projects are based on Spring and I don't really have to look outside of that ecosystem. It almost acts as an aggregator of different open source solutions and often works by abstracting the functionality so that differences are not that big. I…

Yep, with Spring Boot development is so easy, and even decade old projects are mostly easy to upgrade. I don't have experience from C# or .NET development, but at least compared to Python and especially JS ecosystems it's so much better.

Re: Java 27

#64

Post by gentlewater »

marginalia_nu wrote: post #33
Horffupolde wrote: post #15

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

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.

It’s still missing null safety, right? Which means it’s still a hard no for me.

Re: Java 27

#65

Post by papercrane »

rf15 wrote: post #11

> Twelfth Incubator Are you sure this egg is actually viable? I mean, I'd love to see it, but...

The JDK team made a decision awhile ago to hold the Vector API until value types are final. That's why the API has been incubating so long.

Re: Java 27

#66

Post by marginalia_nu »

gentlewater wrote: post #64
marginalia_nu wrote: post #33

Earlier quoted context omitted.

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.

It’s still missing null safety, right? Which means it’s still a hard no for me.

Have you tried not returning null or constructing incomplete objects?

Re: Java 27

#67

Post by LelouBil »

gentlewater wrote: post #64
marginalia_nu wrote: post #33

Earlier quoted context omitted.

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.

It’s still missing null safety, right? Which means it’s still a hard no for me.

You can either use Kotlin then, or simply use java and nullability annotations, they have good support in both IDEs and analysis tools

Re: Java 27

#68

Post by rwyinuse »

Horffupolde wrote: post #15

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

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.

Re: Java 27

#69

Post by PaulHoule »

petilon wrote: post #36
moomin wrote: post #5

C# dev here: it’s amazing how different this is from a Microsoft release. First off, Oracle are doing versions at approximately twice the cadence. But also, and I’m guessing this is a function of the much larger Java audience: things rarely get two preview versions in a proper release. Updates in beta versions, yes, all the time. It also feels like Microsoft are bundling a lot more into the platform and leaving less…

> Microsoft are bundling a lot more into the platform and leaving less to the community. This is a good thing. In Java everything has multiple community offerings, so before doing anything you have to evaluate the community offerings and decide which one to go with. If you go with the wrong one you may end up having to switch at some point, and that can be painful. This happens so often that most of the time spent wh…

Sometimes the thing built into the .NET platform is great, sometime it is just crap but developers will use it anyway and it sets back the ecosystem.

There is this division of labor between systems programmers and application programmers and often we think systems programmers are better because they know more about algorithms and data structures and compilers and assembly language and such. On the other hand, application developers understand how to reconcile the mental model of managers and employees and customers with computers, reality and common sense and, once they get experienced, see the commonalities between all the run-of-the-mill bizapps that we are coding all the time.

Application programmers do a lot better at applications framework than systems programmers and make things like Ruby on Rails and Spring. Systems programmers make terrible things like ASP.NET MVC (I worked out a way to do MVC with ordinary ASP.NET, why couldn't they, with access to the platform internals?)

Post reply on HN