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

81–90 of 423 posts

Re: Java 27

#81

Post by rzmmm »

soco wrote: post #42
Horffupolde wrote: post #15

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…

I use Java for hobby projects, I think it's design choices make it a nice minimalist language for "classic OOP" style: dynamic dispatch, encapsulation etc.

Nowadays a lot of code is written with mostly procedural style with some functional characteristics, I wouldn't use Java for that.

Re: Java 27

#82

Post by gentlewater »

marginalia_nu wrote: post #66
gentlewater wrote: post #64

Earlier quoted context omitted.

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?

Can I trust code I’ve written myself with no guarantees from the language? Maybe. Can I trust code written by dozens of other developers (and/or agents) working on the same project over multiple years? Definitely not.

Re: Java 27

#83

Post by Horffupolde »

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

> 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 a byte array (or URL encoded form field) into a UTF-8 string means handling…

Perhaps you are the trip you expected to blow up first.

Re: Java 27

#84

Post by PaulHoule »

voidfunc wrote: post #62
msluyter wrote: post #55

Earlier quoted context omitted.

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.

Mostly I think they are a mistake, like in ordinary application code instead of catching close to the throw you want to do a lot of

  try {
     ...
  } finally() {
     ...
  }
to make sure things get torn down that have to be torn down and let the exception go to the top of the unit of work and probably to whatever drives the work unit. You can probably do better than logging the raw exception and moving on to the next work unit but you can do much worse. That is, you want a default "sloppy" error handling approach that's correct that you can do without thinking and avoid other kinds of "sloppy" coding encouraged by checked exception such as catching exceptions locally without doing the right thing globally.

Occasionally though I have built something really sensitive, like an authentication filter for a web site which has at least 5 ways to log in and in that I have a hierarchy of exceptions and use checked exceptions heavily to document all the ways things can go wrong and felt like "the type system really has my back here" but that is like 5% of the Java I write.

Re: Java 27

#85

Post by gentlewater »

LelouBil wrote: post #67
gentlewater wrote: post #64

Earlier quoted context omitted.

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

I use Kotlin as my main language and I’m very satisfied with it.

Re: Java 27

#86

Post by pron »

kllrnohj wrote: post #17
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…

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

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 single spec approved by the JCP (https://openjdk.org/projects/jdk/27/spec/). This also makes things easier with regards to compatibility and evolution.

Re: Java 27

#87

Post by kccqzy »

BoppreH wrote: post #44
t0mas88 wrote: post #26

Earlier quoted context omitted.

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

A lot of that is coding style. I’ve also seen a lot of hard-to-debug issues in Python caused by reflection, weird decorators that muck around with name-mangled symbols, and bytecode manipulation. You can even manipulate the traceback object so it’s more difficult to make sense of why the exception comes from.

It took me quite a long time to accept that the recommended unit testing library manipulates bytecode so that the exception message for `assert a == b` prints the values for both.

Re: Java 27

#88

Post by marginalia_nu »

gentlewater wrote: post #82
marginalia_nu wrote: post #66

Earlier quoted context omitted.

Have you tried not returning null or constructing incomplete objects?

Can I trust code I’ve written myself with no guarantees from the language? Maybe. Can I trust code written by dozens of other developers (and/or agents) working on the same project over multiple years? Definitely not.

Why don't you have any coding standards? If you're working with agents in particular, catching and enforcing this stuff should be easier than ever.

Re: Java 27

#89

Post by kittoes »

hirvi74 wrote: post #77
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 kind of wish C# would slowdown releases in some areas. I have not been a huge fan of some of the changes in the past year. I love the performance changes and bits of functionality here and there, but the syntax-sugar is getting annoying.

Interesting take, how is optional functionality annoying? Isn't the fact that it's just sugar a huge benefit? Us old timers can simply stick to what we're familiar with.

Re: Java 27

#90

Post by saghm »

kllrnohj wrote: post #17
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…

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

I didn't read the parent comment as being particularly positive in their description; it didn't sound like it was being stated as a good thing to me.
Post reply on HN