Live data from Hacker News

Java 26 is here

hanno.codes

261–270 of 352 posts

Re: Java 26 is here

#261

Earlier quoted context omitted.

I think there is something to say for compiling to native code, having binaries in the ~25 MiB range, being able to run in distroless containers, being able to run a web application with less than 100MiB of memory and startup times measured in milliseconds rather than seconds (sometimes dozens of seconds). Don't get me wrong, I like Java and don't very much like the Go language. But Java has a lot to improve upon sti…

You can have a <20MiB Graal-compiled binary for a Java project if you use a lean framework like Micronaut. Memory footprint is 5–40 MB RSS.

But with graal isn't the min compile time on avg hardware like a minute?

Re: Java 26 is here

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

That and also the JVM is a marvel of engineering with millions of hours that were poured in by smart people over the last 30 years. It can be as fast a C, supports a multitude of languages, introspection, surveillance etc.

JFR is one of my favorite things about the JVM. Such good tooling to figure out whatever it is you are having problems with in production.

I've also used Eclipse MAT to find tricky dangling references to objects that caused memory leaks. Definitely not as polished, but extremely useful.

Re: Java 26 is here

#264
post #71
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…

Once i heard a manager explain "we must get rid of anything Oracle, including Java, because of license reasons". I see this attitude everywhere since. JavaScript people are too afraid to use Java, that is why something like TypeScript exists. And for personal projects, C# has become a better and more fun "just works" platform.

I mean, sometimes managers are uninformed and say stupid things?

You can use any of the other jdk builds from the plethora of other vendors and have zero interaction with Oracle.

I absolutely hate Oracle as a company, but they've really done a good job with Java stewardship. They actually open sourced the entire language / jdk and a lot of the tooling that used to be proprietary.

They still love to play the old Oracle tricks, so I'd rather not use any of their distributions. But the actual work that they do on the ecosystem has been a positive in my opinion.

Re: Java 26 is here

#265
post #212

Earlier quoted context omitted.

Go can't compete with Java bc it's not in the same category as Java. - Java is a high-level, multi-paradigm programming language - Go is designed as a systems language to supersede C projects at Google Now Go identifies as a general purpose language that competes with Java? It's a free country, I guess.

How is Go not high level? What makes it "systems" language? That's just marketing. It is a language with a fat runtime, running a garbage collector. You just burn it into the binary and call it a day.

(just like modern Java can burn its runtime / GC into the binary)

Re: Java 26 is here

#266
post #213

Earlier quoted context omitted.

Are you sure about Go's garbage collector doesn't have pauses? AFAIK they are worse than modern Java's garbage collector [1]. I'm not sure it's even better than Java's, especially for modern ZGC (and you can choose your GC in Java). Definitely less configurable. I would say most of online comments about Java's GC are long outdated. For example, in web servers a lot of work is request-response, so it's convenient to u…

Java's GCs (plural) are hands down better.

Hell, I even had a use case where serial GC was actually the correct choice (small job runner process that needed to be extremely low memory overhead). It's nice having options, and most of those options are extremely good for the use cases they were designed for.

Re: Java 26 is here

#267
post #194

Earlier quoted context omitted.

Any time you have a barrier between one function being able to call another. The original article on this called them red functions and green functions. A green function can call a red function but a red function can't call a green function. In terms of async, it's when you have to have a function with "async" attached to it and making it so that only other async functions can call async functions. It ends up creatin…

The coloring is a property of concurrency safety and whether the language enforces it. For instance, if you resolve a future in the wrong context you'll still have problems - the coloring is just a compile time error that you are doing things wrong, rather than a runtime deadlock.

Right, and a lot of people would rather avoid that issue altogether by using a different concurrency model.

Re: Java 26 is here

#268
post #110
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…

I wonder if at we are standing looking at the smoking field of programming languages created over the last 50 years and gazing at the final survivors, of which Java is definitely one. 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. I learned IBM /360 assembler when I started in comp…

Most of my 20 years of experience is Java. Now 3 years into a new job mostly using Python to build microservices. I feel much more productive using Python (plus uv, ruff and mypy for fast repeatable package management, linting and type checking). I see Python having a trajectory to keep improving and gaining more adoption - eg Python keeps growing in popularity https://survey.stackoverflow.co/2025/technology/. It will have real threads soon and better type checking with ty (thanks to astral who also make uv and ruff). Python gives an incredibly tight integration loop since you don’t wait on compiling. Our kotlin projects are always at least 2x slower for ci/cd builds. I like typescript, but working with it in IntelliJ is incredibly slow.

Re: Java 26 is here

#269
post #232
post #83

Earlier quoted context omitted.

> As for build systems, Maven is old and cranky but if something else replaces it, it will probably be quite similar anyway. Bazel is the most obvious contender and very different from Maven in almost every possible way.

Not really, no. It is similar but worse than Maven in that it requires quite a bit of time investment to configure, and shares the drawback of Gradle that it is configured in a programming language instead of a configuration language. Switching out Maven for a larger maintenance burden might be reasonable in a large organisation that is swimming in competent employees, but most do not. As for obvious contender, I'd s…

Did everyone just agree to forget about Gradle? It was everywhere not too long ago. I think I even prefer it to Maven, in a choice between a rock and a hard place type of way.

Re: Java 26 is here

#270
post #145

Earlier quoted context omitted.

Didn't they all switch to convention over configuration and dependency injection so now your configuration is your source code?

Some people did but that's actually worse. Your configuration comes magically out of nowhere and when it breaks you can't fix it.

Nobody ever wanted to wire up RPC endpoints, in the form of Enterprise JavaBeans(tm), using XML files. That is one for the history books of ridiculous technology.
Post reply on HN