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

161–170 of 427 posts

Re: Java 27

#161

Post by pmontra »

t0mas88 wrote: post #26
Horffupolde wrote: post #15

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

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

It works well enough with plain Ruby and plain Javascript. It ported a Rails 7, Vue 2, vuetify 2, vuex app to Rails 8 (ok, easy, I did it myself at least once), Vue 3, Vuetify 4, Pinia. I had to visually check the SPA, of course.

Re: Java 27

#162

Post by troupo »

theandrewbailey wrote: post #16
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…

I never thought of Java being the 'move fast ~and break things~' alternative over .NET, but Java has a faster release schedule to get features out sooner.

> Java has a faster release schedule to get features out sooner

While still being behind on most features?

Re: Java 27

#163

Post by bob1029 »

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…

> If you go with the wrong one you may end up having to switch at some point, and that can be painful.

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

https://learn.microsoft.com/en-us/dotnet/core/install/window...

Re: Java 27

#164

Post by pron »

kllrnohj wrote: post #148
pron wrote: post #86

Earlier quoted context omitted.

The Java language and runtime have been co-designed as a unified platform for many years now. Virtually every significant feature has language, library, and VM people working on it, and we often don't even know when we start how much of the feature would be in the language, library, or VM. Consequently, there is no "language version" or a "runtime version". There's only a platform version, which is defined in a singl…

> There's only a platform version, And of the 4 non-preview JSRs in the Java 27 release, only 1 of them is actually part of the "platform version". The other 3 are strictly changes to Hotspot internals with no platform involvement at all. They did not change any aspect of any Java platform in any way whatsoever. That is what I'm referring to. I'm not referring to the fact that the core library, language syntax, and r…

Right. There's a "Java SE" (platorm spec) version, and a JDK version that corresponds to it, but not everything in the JDK affects or is dictated by the spec.

BTW, Java is developed "code first", which means that we first work on the implementation in OpenJDK, and then extract the relevant spec changes from it.

> But that is still somehow a "feature" of the Java 27 release according to Oracle.

It's a feature of the OpenJDK JDK, which is, indeed, the Java implementation done by Oracle (with contributions from others). The language is very careful, as you can see in the announcement: "JDK 27, the reference implementation of Java 27". The Java SE 27 spec is here: https://www.jcp.org/en/jsr/detail?id=402

Re: Java 27

#165

Post by doublepg23 »

dorkypunk wrote: post #123
doublepg23 wrote: post #115

Earlier quoted context omitted.

Why not Kotlin?

Most organizations that use Java tend to be pretty conservative with their technology picks and nowadays with newer Java versions the only real gap with Kotlin is null-safety which is supposed to also come to Java at some point. There is also an organization culture component most of the time, one our engineers actually proposed to use Kotlin for one of the new projects but it got rejected because "We are a Java shop…

Are you guys keeping up with the Java LTS releases?

Re: Java 27

#166

Post by jeffbee »

Thaxll wrote: post #45
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.

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.

Java is almost always significantly faster than Go because the Go runtime does a poor job of exploiting large memory page, doesn't support text-on-huge-pages, and barely supports profile-guided optimization. With HotSpot you get all of this and more for free. Go is fine but Java is peak.

Re: Java 27

#167

Post by derefr »

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…

> Also, the page reads like an open source “We’re finished, we’re tired.” announcement rather than the razzmatazz of a Microsoft release.

I think this is because the JRE/JDK upstream releases are a bit like Linux kernel releases: all the major first-party feature development goes on in subprojects that maintain their own "living forks" during feature development, with the teams on these features doing PRs against the fork's own "main"; that "fork's main" having its own subproject maintainers who ensure a mess isn't made of it; and then those maintainers eventually polishing up that fork-main into a single big one-shot PR to upstream once the feature-as-a-whole is ready.

(Compare/contrast: the Linux kernel's mm, rt, and kvm feature development efforts.)

Because of this, the top-level "project maintainers" (i.e. the people who decide what gets merged into upstream main) aren't really the same people as these subproject people who care deeply about these new features. They want to ship stuff people want, but they personally mostly deal all day with requests to merge 1. small bugfixes, and 2. features so small that no JEP is needed.

But then, every once in a while, they have to deal with a request to merge one of these huge subproject upstreaming PRs. And sure, it's already heavily reviewed by the subproject's maintainers, who they trust. But they do still have to audit it and learn it and create a stabilized release path for it. "Handover" stuff. And that's tiring!

So, given that the toplevel project maintainers write the release notes, I'm not surprised they come off as weary about releases.

(That being said, for purely PR reasons, the toplevel maintainers could ask the subproject staff to contribute their perspective to the release notes of a release that merges their work? But this could also just-as-well be a separate blog post—which would probably be better for sharing. I don't think I've ever seen a centralized Java blog [is there one?] but I think the subproject teams do tend to have them.)

Re: Java 27

#168

Post by jeffbee »

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

Isn't this mostly about java cold start costs? It might be that other people are optimizing for steady-state performance, not transient startup performance.

Re: Java 27

#169

Post by ivan_gammel »

pmontra wrote: post #155
ivan_gammel wrote: post #128

Earlier quoted context omitted.

It is really not a big deal nowadays, the problem of the same scale as having index out of bounds error (no language has good defence against this, yet it is not a catastrophe).

That's expected (the index out of bound). You have an array, and maybe it grows, you read a number from input, you don't check it against the size of the array because you want to torture the language, use it to get the element at that index and... I'm sure that there is a surprisingly number of different designs of what it should happen and a number of designed ways to ensure that it doesn't happen. But a runtime er…

yes, so are the NPEs - both are runtime errors indicating a bug in the code. NPE was a major source of irritation 20 years ago, but what many people do not know is that debugging NPEs in Java is easier now - they carry more information about the source. And the culture has evolved.

Re: Java 27

#170

Post by Romario77 »

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…

the release cycle time was a deliberate choice.

Java tried to do fairly large updates and sometimes the release cycle would be very unpredictable as things would slip and take much longer than anticipated.

So to make it more predictable and to keep updates coming they switched to 6 months cadence with long term support (LTS) every two years.

This I think is a pretty good way of doing things, makes people who plan things figure out how to split feature development into these 6 months cycles, it made JEPs more granular and I think it made project Valhalla possible, if they tried doing it the old way it would never happen.

Splitting things in small chunks clarified what needs to be done and the path forward. It still takes very long time, but doesn't cause big incompatible changes and I think overall Java has good progress without being stalled.

Post reply on HN