Java 26 is here • Hacker News Board

Re: Java 26 is here

#331

Post by gf000 » Thu, Mar 19, 2026, 8:41 AM UTC

deepsun wrote: post #310

spopejoy wrote: post #274

Earlier quoted context omitted.

TIL Mill, I've been in build hell trying to package a javafx GUI gradle project that depends on a non-module-ified lib (usb4java, long story, no I can't use anything else). Beryx/badass failed entirely, was able to get something working with Gradle doing jlink and manual CLI jpackage ... But tbh the whole experience makes me distrust the Java ecosystem if you're supporting anything that is slightly out of the communi…

I feel like Gradle is only relevant for Android. All other projects are fine with Maven (and I like a lot that Maven doesn't allow to code in the build config, any complex logic should be extracted to a custom build plugin, using real code. I just have PTSD after some build.gradle monstrosities).

It's just that Maven doesn't have a good core abstraction and it is not a reliable build system. Like even with base plugins, let alone with additional ones you can't be sure that a build actually picked up every change, you often have to do a double take and do a clean install instead to get some stale files cleared. This should never happen in a build tool and every other feature is secondary to this error.

That's why I defaulted to Gradle, which has its own idiocities (like tending to break the syntax on every second major version, but it's much better with the kotlin DSL), which at least 100% sound.

For more experimental/hobby projects I choose mill though.

Re: Java 26 is here

#332

Post by pjmlp » Thu, Mar 19, 2026, 12:54 PM UTC

freedomben wrote: post #280

pjmlp wrote: post #30

Earlier quoted context omitted.

It isn't, check Gerrit commit history, they only take bits and pieces, plus ART doesn't do all bytecode equivalents. Some JVM bytecode don't have counterparts in Dex, rather get desugared into multiple instructions.

Was ART better at the time they wrote it? Do you know if there were any reasons other than perhaps legal, that caused them to go that route?

Mostly not wanting to pay Sun for Java Embedded licenses.

https://venturebeat.com/ai/google-sun-wanted-money-for-andro...

The problem isn't ART per se, embedded Java vendors also have their own internal implementations, but the big difference is that they pay for their licensing and support standard Java.

Re: Java 26 is here

#333

Post by Mawr » Thu, Mar 19, 2026, 4:24 PM UTC

pron wrote: post #134

dzonga wrote: post #37

the people that work on Java & the JVM are very smart. it has become a best of breed language - hell its better than Go for industry purposes. the drawback with Java will always be the CULTURE - (maybe someone can insert a quote of how in physics progress is only made, when old physicist die - I don't wanna be morbid ) but with Java same that's when the culture will change. All those people using typescript (could be…

And Java has some advantages that are hard to beat. It performs better than Go and builds just as fast (at least when not using some popular build tools) while offering unmatched deep, low-overhead observability. People might think they may enjoy another language more, but the portion of people who eventually come to regret choosing Java is probably lower than that of any other language.

> It performs better than Go > and its optimising compiler and GCs blow Go out of the water without breaking a sweat.

Well, dandy! Since the performance gap is that big, it should be trivial to get hard data backing that up. Mind linking some representative benchmarks?

Dang, I just can't wait, same resource usage for Go and Java (RAM in particular, if you would), and Java performance that "blows Go out of the water".

> and builds just as fast

Oh? But you're comparing apples to oranges.

Go builds its source into a machine code executable, all optimizations are applied at this step. This then gets directly executed by the CPU.

Java "builds" its source into bytecode. It's a trivial transformation that then needs to actually be compiled and optimized by a virtual machine at runtime before the CPU can run it.

So then, what build time does Java have when doing AOT compilation? Again, hard numbers please, thanks.

> while offering unmatched deep, low-overhead observability.

> People might think they may enjoy another language more, but the portion of people who eventually come to regret choosing Java is probably lower than that of any other language.

Very believable statements, given that you literally work on Java for Oracle :) No need to bother to make a disclaimer about that I guess. Shameless.

Re: Java 26 is here

#334

Post by zadikian » Thu, Mar 19, 2026, 6:51 PM UTC

owlstuffing wrote: post #314

zadikian wrote: post #313

Earlier quoted context omitted.

The error handling is like a systems language for sure, I'll agree on that. But where do Go's docs or founders call it a C replacement? gf000 asked where this is mentioned besides marketing, but I don't see it in the marketing either.

Now that Go is styled as a Java competitor its framing is different. But here's an old golang.org archive for fun: https://web.archive.org/web/20091113154831/http://golang.org... The main page title *Go: a systems programming language* It still sports all the low-level stuff too, pointer arithmetic and all.

Thanks. I'm not surprised they called it a C++ competitor back then. All those systems-style features do make it awkward now that it's targeting the Java-like use cases. No pointer arithmetic, but pointers yeah, and it's not very clear what you're supposed to pass by value vs by ref. You can do things like a DBMS in Go that count as systems programming, but for sure it's not a competitor with C.

Go happened to be attractive for web backends too because it had good greenthreading before Java etc did, and better performance than JS, so it makes sense that they changed the marketing.

Re: Java 26 is here

#335

Post by munksbeer » Thu, Mar 19, 2026, 6:52 PM UTC

dinkumthinkum wrote: post #190

thefaux wrote: post #139

Earlier quoted context omitted.

> Why would anyone create a new language now? The existing ones are "good enough", and without a body of examples for LLMs to train on, a new language has little chance getting traction. Compiler writing can be an art form and not all art is for mass consumption. > Java has won (alongside many other winners of course), now the AI drawbridge is being raised to stop new entrants and my pick is that Java will still be h…

> This makes no sense to me. If AI possesses intelligence then it should have no problem learning how to use a new language. If it doesn't possess intelligence, we shouldn't be outsourcing all of our programming to it. Perfection. You have made such an excellent. However, I don't want to detract from that but it's like, in reality, this is a completely obvious point but because of this AI/LLM brain-rot that has taken…

> this is a completely obvious point but because of this AI/LLM brain-rot that has taken over the software programmer community

This is really insulting. I think you're wrong, AI agent programming is very good now, and you will have to admit it at some point.

Re: Java 26 is here

#336

Post by owlstuffing » Thu, Mar 19, 2026, 7:03 PM UTC

gf000 wrote: post #326

owlstuffing wrote: post #314

Earlier quoted context omitted.

Now that Go is styled as a Java competitor its framing is different. But here's an old golang.org archive for fun: https://web.archive.org/web/20091113154831/http://golang.org... The main page title *Go: a systems programming language* It still sports all the low-level stuff too, pointer arithmetic and all.

And a fat runtime with a garbage collector. Like people can write all sorts of programs with a GC, that was never the issue. But then just stay truthful, otherwise C# is also a system PL.

"Fat" runtime? Go? Nah.

Go's runtime is thin: goroutines, a GC specialized for concurrency, networking, and little else. Java, by contrast, assumes a JVM plus massive stdlibs to handle everything from enterprise apps to big-data, making its platform genuinely "fat" and layered. Other Java-tier languages, C# included, follow the same model.

Re: Java 26 is here

#337

Post by zadikian » Thu, Mar 19, 2026, 8:04 PM UTC

owlstuffing wrote: post #336

gf000 wrote: post #326

Earlier quoted context omitted.

And a fat runtime with a garbage collector. Like people can write all sorts of programs with a GC, that was never the issue. But then just stay truthful, otherwise C# is also a system PL.

"Fat" runtime? Go? Nah. Go's runtime is thin: goroutines, a GC specialized for concurrency, networking, and little else. Java, by contrast, assumes a JVM plus massive stdlibs to handle everything from enterprise apps to big-data, making its platform genuinely "fat" and layered. Other Java-tier languages, C# included, follow the same model.

I agree Go's runtime is as thin as runtimes get. But having a runtime at all disqualifies it from being a C replacement. Rust is trying to replace C, Go is trying to replace Java and some of C++.

Re: Java 26 is here

#338

Post by deepakarora3 » Thu, Mar 19, 2026, 8:25 PM UTC

nekitamo wrote: post #236

mands wrote: post #58

Earlier quoted context omitted.

It's getting better, it doesn't all have to be Spring Boot and JBoss. There is quarkus, helidon and micronaut for slimmer more modern backend frameworks. jbang for scripting (think uvx, bunx), Tambo UI ( https://tamboui.dev/ ) for terminal UIs, and more. Along with all the new Java features that help you write much simpler code - eg. virtual threads, structured concurrency, stream gatherers, and performance / resourc…

I'd like to mention the web framework I'm using these days, Jooby: https://jooby.io/ I've found it quite satisfying compared to the other "new" ones. As for the original topic, I just want to echo what others have said, and say that I am happiest in Java when writing it as if it were Golang code. That an the first-class runtime and performance and deep ecosystem make it a great choice in 2026.

I one hundred percent support the above. Jooby is a great performant framework, simple to use with tons of flexibility and features. Super happy with it!

Re: Java 26 is here

#339

Post by gf000 » Thu, Mar 19, 2026, 9:40 PM UTC

owlstuffing wrote: post #336

gf000 wrote: post #326

Earlier quoted context omitted.

And a fat runtime with a garbage collector. Like people can write all sorts of programs with a GC, that was never the issue. But then just stay truthful, otherwise C# is also a system PL.

"Fat" runtime? Go? Nah. Go's runtime is thin: goroutines, a GC specialized for concurrency, networking, and little else. Java, by contrast, assumes a JVM plus massive stdlibs to handle everything from enterprise apps to big-data, making its platform genuinely "fat" and layered. Other Java-tier languages, C# included, follow the same model.

Even Rust has a runtime. Compared to that Go's is absolutely fat though.

Re: Java 26 is here

#340

Post by troad » Thu, Mar 19, 2026, 11:35 PM UTC

gf000 wrote: post #330

troad wrote: post #299

Earlier quoted context omitted.

I'm not using OOP to mean presently unpopular facets of OOP, to the exclusion of presently popular ones, I mean all of OOP. It's pretty hard to need factories, let alone factory factories, when one isn't using objects or classes. A friendly joke in response to the claim that sufficiently complex code always ends up sprouting OOP abstract nonsense.

Unless you are using a strictly FP language, you are always basically using objects. And all the stuff like factories and everything exist in FP as well, it's pretty short sighted to say otherwise. These are patterns that may or may not be useful in a given case. Sometimes a language feature can replace them (e.g. pattern matching ~ visitor pattern, but not even this is a full match see closed vs open hierarchy), but…

I do mostly use a strictly FP language, but it's trivial to use Java (C#, etc) as FP languages too. Just use classes as stateless function namespaces. FP Java is best Java.

> And all the stuff like factories and everything exist in FP as well, it's pretty short sighted to say otherwise. These are patterns that may or may not be useful in a given case. Sometimes a language feature can replace them (e.g. pattern matching ~ visitor pattern, but not even this is a full match see closed vs open hierarchy), but in most cases you just call them something else/don't have that problem because you are not writing that big of a software.

This is precisely the viewpoint that made me want to reply to the original comment. If you live and breathe OOP, you see OOP design patterns as solutions, because you've run into OOP problems that they solve. FP code does not tend to run into OOP problems, and ergo does not tend to utilise OOP solutions to those problems. I appreciate this can be hard to imagine, but I respectfully suggest you have some OOP blinders on if you're so confident everyone is using factories that you attempt to size-shame FP codebases you've not even seen so you can remain in the right. :)

The purpose of factories is to decouple object creation and use. But FP already does this by never coupling behaviour and data in the first place. Think about it. If data is in a simple struct, with no member functions, ideally immutable, what kind of factory could you possibly need? How would it even work? What kind of problem could it possibly solve?

To say nothing of e.g. the Visitor pattern, which is an approximation of functional styles using OOP. There is no need to define some small subset of behaviour outside a class, and then hook up boilerplate machinery inside that class to run that behaviour (ie the Visitor pattern) if all behaviour is always defined outside the class. The Visitor pattern solves a problem that arises only in OOP, due to its penchant for stateful data-code coupling, and it does so with a sprinkling of FP. It's incoherent to speak of a Visitor pattern in FP code. It's an OOP solution to an OOP problem.