Live data from Hacker News

Java 27

mail.openjdk.org

41–50 of 424 posts

Re: Java 27

#41
post #23

Earlier quoted context omitted.

Wouldn't you go with golang in that case?

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

Re: Java 27

#42

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

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.

Re: Java 27

#43
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…

> First off, Oracle are doing versions at approximately twice the cadence Is that actually a good thing? But Oracle started playing a game, for better or worse, where they decided to couple the "language version" with a single specific runtime's release schedule. For example, in "Java 27" there are exactly 0 language changes and 1 minor feature addition to the TLS library. Everything else is OpenJDK runtime internals…

There's not really a second C# runtime. Java has several, some based on the Openjdk, but a few that are completely new like OpenJ9 and Graal.

The closest C# has is mono.

This sort of thing is bound to happen with that situation. Heck, it happens with C++ whenever a new C++ version comes out. Some C++11 features took years to make their way into all the compilers.

Re: Java 27

#44
post #26

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…

> 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.

Re: Java 27

#45
post #23

Earlier quoted context omitted.

Wouldn't you go with golang in that case?

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.

Re: Java 27

#46
post #6

Earlier quoted context omitted.

G1 is now the default garbage collector in 27.

Sorry I only just set -xXx360NoScopexXx=4G to run that latest version without hitting OOM and you are right, it is indeed quite fast with G1.

You misunderstand, xxx360NoScopexxx is now the default.

Re: Java 27

#47

Earlier quoted context omitted.

> First off, Oracle are doing versions at approximately twice the cadence Is that actually a good thing? But Oracle started playing a game, for better or worse, where they decided to couple the "language version" with a single specific runtime's release schedule. For example, in "Java 27" there are exactly 0 language changes and 1 minor feature addition to the TLS library. Everything else is OpenJDK runtime internals…

You’re only counting JEPs, which are only for more involved features. There are lots of changes to the JDK apis that are used by other runtimes. See, for instance: https://javaalmanac.io/jdk/27/apidiff/26/ . Admittedly, the terminology here is almost designed to be maximally confusing, and I’ve never read a good post that laid out how everything relates.

Fair, although even there I don't know if I'd call that "lots" at just 23 added or modified methods that aren't in preview

Re: Java 27

#48

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

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.

Re: Java 27

#49
post #10

Project Valhalla will go into Java 28 (next year, and preview version). Fingers crossed I'll manage to use null type safety in my lifetime.

[deleted]

Re: Java 27

#50
post #14
post #10

Project Valhalla will go into Java 28 (next year, and preview version). Fingers crossed I'll manage to use null type safety in my lifetime.

universal null type safety has sadly been discarded as a core concept of Valhalla in my Understanding; that being said, the proposals in Valhalla have null-safety as a side effect, but only under certain conditions.

When (if) null safety ships, I‘m not sure I can justify using Kotlin any longer.

Java simply got too nice.

Post reply on HN