Live data from Hacker News

Java 27

mail.openjdk.org

181–190 of 427 posts

Re: Java 27

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

I don't think modern Java is a 'move fast ~and break things~' environment. It's a comparatively stable platform with an enviable focus on backwards compatibility. The maintainers have talked about "last mover's advantage" when it comes to introducing new language features. Java has a checkered history when it comes to novel programming language features, so I think this is good.

Granted, the maintainers are more inclined to deprecate and remove parts of the API than has historically been the case but it is mostly obsolete things like applets. And you may need to keep a close eye on runtime flags and their effects.

Re: Java 27

#182
Java consistently introduces lots of exciting functionality into the language. That's a big part of my dislike and active avoidance of it.

Re: Java 27

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

One difference I think about is generics. Java and .NET bolted generics on to an existing system. Java used type erasure in such a way that a List is really just a List. Type erasure has a lot of limitations. If I am coding in Java for days I never get into trouble with it because I know how to color in the lines. But do some balls-to-the-walls metaprogramming and then it is annoying that you can't write

   Expression add(Expression a, Expression b);
   Expression add(Expression a, Expression b);
because in the end they both look like

   Expression add(Expression a, Expression b)
we have ways to cope, like unerasing the types by rewriting the names... And now you've got a reason to do balls to the walls metaprogramming! Similarly if I do a lot of C# or Scala or something I will get into the habit of doing things I can't do in Java.

.NET on the other hand did not keep backwards compatibility, so a List is not a List so .NET had a schism where some API functions use generic collections and others use non-generics which was annoying in its own way.

Something like that is how all methods in Java are virtual whereas methods in C# may or not be virtual. All-virtual is probably not the best for performance, but it is simple for understanding. You never have to think "do I make this virtual or not?" or think "is that method virtual or not and does that have consequences for how I use it?"

Re: Java 27

#184
post #162

Earlier quoted context omitted.

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?

To misquote Bart Simpson:

> Let me get this straight: we're behind the [other languages] and we're going to catch up to them by going slower than they are?

Gotta go faster if you ever wanna catch up. However, Java is also purposefully slow. Everything is extremely considered. And while it means it takes a while before you get a feature it tends to be pretty good.

Re: Java 27

#185

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

It's a stable known stack. It's not hard to find Java developers and the AI Agents are probably pretty good at writing Java too. A Java backend will just sit there and do its job happily forever and you can bolt on whatever front-end you want. Spring Boot has been kind of the standard way to do Java web applications for probably a decade if not longer. It works fine has all the bells and whistles when you're ready for them and most Java developers who work on the web know Spring already.

As for an individual developer doing a side project, you should use Java if you haven't used it before to get exposure to it. It's a fundamental component of enterprise software and if you've never used it before take the time to learn something new.

Re: Java 27

#186

Java consistently introduces lots of exciting functionality into the language. That's a big part of my dislike and active avoidance of it.

[deleted]

Re: Java 27

#187
post #112

Earlier quoted context omitted.

Most engineers do not have the ability to impose rules by fiat on all of their coworkers. It seems like you're misunderstanding the nature of working on a codebase as an IC when other developers contribute to it. If all of my coworkers don't want a lint rule I propose, I don't get to add it. If all of my other coworkers want to write code in a certain way and approve each other's MRs with code written in that way, I…

Most engineers don't get to decide to use a language either. Usually someone with the clout to pick a language has the clout to set style requirements too.

I don't disagree, but that sounds more like a response to the person asking "what's the argument for picking Java?" than one to the someone who finds "Have you tried not returning null or constructing incomplete objects?" and "Why don't you have any coding standards?" to be poor takes.

Re: Java 27

#188

Java consistently introduces lots of exciting functionality into the language. That's a big part of my dislike and active avoidance of it.

In the absence of a sarcasm tag, would you care to explain your reasoning?

Re: Java 27

#189
post #172
post #94

Earlier quoted context omitted.

These days, Java is mostly used in greenfield software that has to be very reliable, very performant, and last for many years. So it's often the first choice for banking, telecom, finance, government, defence, manufacturing control, logistics and shipping, media streaming, retail, hospitality, healthcare etc.. It's usually not a first pick for more exciting software, such as Python type checkers, JS bundlers, or TUI…

This is quite the take - i doubt most startups building in these spaces are using Java.

i can't speak to the others but banking and healthcare is virtually all java top to bottom. The big healthcare EMR/EHR systems are Java and every bank i've ever worked with (i use to do a lot of integrations with the big banks) was all Java. I have friends in those areas and whenever they start up a new project it's still always Java since that's where their skills are and what's on the "approved tech." list.

Re: Java 27

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

NullAway with JSpecify annotations are a really good way to add null safety to Java applications. Even enforces nullability at the generic level.

The elephant in the room is the standard library (collections). It isn't even type safe yet, because some methods were around before generics were added. And collections are too core for anyone to be able to agree on a 3rd party standard.
Post reply on HN