Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java 26 is here

hanno.codes

Post reply on HN
Print view View original

271–280 of 352 posts

Re: Java 26 is here

#271

Post by gf000 »

steve-atx-7600 wrote: post #268
beachy wrote: post #110

Earlier quoted context omitted.

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

Java compiles as fast as go, so not really sure what's the problem - you can basically use it in an "integration loop" with no problem.

Re: Java 26 is here

#272

Post by gf000 »

winrid wrote: post #261
lenkite wrote: post #259

Earlier quoted context omitted.

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?

Yeah, but you only have to do that before shipping. You can just test/develop with "normal" java, you even get hot-reloading.

Re: Java 26 is here

#273

Post by never_inline »

Nursie wrote: post #235
never_inline wrote: post #204

Earlier quoted context omitted.

It was a while back (when I was a worse programmer) I found both Micronaut and Quarkus dev experience more palatable than spring. what did you dislike? Pervasive DI? Annotations? configuration mess?

Never done much Spring, so I don't have a lot to compare to. But ... I'm not a massive fan of using annotations in concept, because they obfuscate what's taking place. Unlike in (say) Python, where annotations are effectively functions wrapping the function they annotate, in java they're more akin to a customisable preprocessor. Obviously I do use them, liberally, because that's the way things are done, but I'm not a…

> Unlike in (say) Python, where annotations are effectively functions wrapping the function they annotate, in java they're more akin to a customisable preprocessor.

I find that Python decorators can do as much magic as an annotation processor - due to the dynamism of Python. Annotation processors, in most cases, produce a new class based on annotations on existing class / interface. The injection of that class is done by the DI container (unless it's a standalone annotation processor like mapstruct).

> And using any modern framework relies on these a lot.

To be fair to language designers, it's hard to avoid code generators. And they're a compelling thing compared to building proxy objects / DI / decorator / dataclass etc.. kind of functionality in language and getting it wrong.

> ... then you have to dig into source to figure out

Agree. It's not a "boring technology" yet.

> For all it's called micronaut, the produced packages are pretty huge.

How huge? And jlink or graal vm? Just curious.

> A lot of this seems to be down to hibernate,

With micronaut atleast, I remember using Micronaut Data JDBC. Anything is better than hibernate.

> In general I think that serverless is such a different paradigm from a long-running server.

Agreed.

Re: Java 26 is here

#274

Post by spopejoy »

pregnenolone wrote: post #246

If we ignore the fact that value types likely won’t ship before we have flying cars, Java has evolved greatly. I really like how they’ve solved concurrency, but I dislike how they’ve handled modules but this a minor issue. The main problem with Java has always been its build tools. They’ve consistently been bad and continue to be. Even today, creating a bundled application with a stripped down JDK with jlink and jpac…

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 community's view or priorities. Even JavaFX shows very patchy support for certain very standard UI concepts, and the situation with packaging is bad as you say.

Anyway, is mill worth switching away from Gradle? (Does mill integrate at all with idea?)

Re: Java 26 is here

#275

Post by jillesvangurp »

gf000 wrote: post #111
jillesvangurp wrote: post #88

Earlier quoted context omitted.

Some of the standard library stuff could be usable from Clojure and other languages. The jvm level optimizations (garbage collection) should benefit all jvm languages. The language changes are mostly not that relevant unless you program directly in Java. I use Kotlin myself (after doing Java since 1995). Most of the overview here reads like they are adding a lot of stuff that Kotlin has had for many years. Structured…

Java improvements usually have a runtime component, so no, kotlin simply couldn't have had Lazy no matter what. It was just syntactic sugar for a getter.

"Just syntactic sugar"

That's what most modern programming languages provide. Syntax matters. Kotlin offers a lot of syntactic sugar for things that are a bit verbose in Java.

The new structured concurrency stuff in Java is actually a great example of that. More or less does the same thing, Kotlin manages to do it with a nice Kotlin DSL. Java does it with a lot of builders and function chaining. Which is a lot less readable.

In the end, Java caught up and you can now use this for more complex concurrent/parallel code (both should be possible with this, like it is with co-routines in Kotlin). Which is a good thing.

Re: Java 26 is here

#276

Post by Capricorn2481 »

hocuspocus wrote: post #253
HendrikHensen wrote: post #219

Earlier quoted context omitted.

I mean, what is old? How far along are frameworks these days, and what are companies using? That team was using Java 17. Java 21 was just released and frameworks had no meaningful support for virtual threads whatsoever. In my experience, most companies using Java are chronically multiple versions behind (e.g. some of my friends still in the Java world are on 11). Perhaps you can share some sources which prove that Ja…

> Java 21 was just released and frameworks had no meaningful support for virtual threads whatsoever. Spring was ready on day 1, as virtual threads had been an experimental feature since Java 19. Spring Boot added support within a couple months. > In my experience, most companies using Java are chronically multiple versions behind (e.g. some of my friends still in the Java world are on 11). And that's on you.

>> In my experience, most companies using Java are chronically multiple versions behind (e.g. some of my friends still in the Java world are on 11).

> And that's on you

What most companies do is on them?

Re: Java 26 is here

#277

Post by e3bc54b2 »

mands wrote: post #58
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…

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…

> a better build system is sorely needed - one of the things that Go / Rust did right

Honestly there are only two reasons I wouldn't pick up Java for personal projects, difficult to build single executable (Graal is still very un-ergonomic), ridiculous build systems.

I can kind of live with former, but Gradle is so very extraordinarily terrible that I don't know where to begin. Problem is, it solves some real problems (in extremely bad way) that people keep using it.

I long of a cargo-style revolution in Java world. (No, the newly popped up alternatives haven't really cut it so far)

Re: Java 26 is here

#278

Post by gf000 »

jillesvangurp wrote: post #275
gf000 wrote: post #111

Earlier quoted context omitted.

Java improvements usually have a runtime component, so no, kotlin simply couldn't have had Lazy no matter what. It was just syntactic sugar for a getter.

"Just syntactic sugar" That's what most modern programming languages provide. Syntax matters. Kotlin offers a lot of syntactic sugar for things that are a bit verbose in Java. The new structured concurrency stuff in Java is actually a great example of that. More or less does the same thing, Kotlin manages to do it with a nice Kotlin DSL. Java does it with a lot of builders and function chaining. Which is a lot less r…

Didn't mean to say that syntactic sugar is bad. But when Java touches a language feature they prefer doing it only when absolutely necessary and even then having the biggest part be in the runtime if possible. E.g. in the lazy case, it's backed by runtime optimizations, they are treated as proper constants. A fancy getter over a lambda is not the same thing, and that's all syntactic sugar in this case would give you.

Re: Java 26 is here

#279

Post by gf000 »

spopejoy wrote: post #274
pregnenolone wrote: post #246

If we ignore the fact that value types likely won’t ship before we have flying cars, Java has evolved greatly. I really like how they’ve solved concurrency, but I dislike how they’ve handled modules but this a minor issue. The main problem with Java has always been its build tools. They’ve consistently been bad and continue to be. Even today, creating a bundled application with a stripped down JDK with jlink and jpac…

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…

Mill does work with idea (via the build server protocol), and the ideas behind it are very sound (a build tool is basically a function calling other functions - on which they depend. You just want to parallelize their running and cache their results.

But it does have a learning curve and you may sometimes end up having strange error messages. (As an implementation, it's basically Scala macros turning normal looking scala functions into a static task graph). It is getting better and better support for mainstream java build setups, and it's possibly the best tool for something very custom. In between the two extremes, you may or may not have a better time with Gradle/Maven.

Re: Java 26 is here

#280

Post by freedomben »

pjmlp wrote: post #30
cogman10 wrote: post #14

Earlier quoted context omitted.

A little bit of all of the above. Android's usage of Java started right as Sun was being acquired by oracle and right before the jdk was GPLed. ... And I'll be. Apparently Android is using the OpenJDK since Android 7. [1] [1] https://en.wikipedia.org/wiki/Android_Nougat

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?
Post reply on HN