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

221–230 of 352 posts

Re: Java 26 is here

#221

Post by HendrikHensen »

gf000 wrote: post #205
HendrikHensen wrote: post #202

Earlier quoted context omitted.

> It performs better than Go Do you have some sources or experiences to share on this topic? I'm very curious. My experience is the complete opposite. At my previous job there was a Java web application and running in Kubernetes (1 vCPU and 1Gi of memory) was able to deal with at most 80 requests per second, using up almost the full 1 vCPU and ~600-700MiB of memory. That was a bit disappointing, since we were suppose…

Well, what frameworks were used? Also what is behind the web requests, what were they doing? Because it's comparing mostly frameworks, not languages. As for the build tools, unfortunately the scene is not the best on Java - but javac itself is indeed fast.

Yeah javac is pretty great. I was doing Kotlin for some time and I was getting very annoying by how much slower and slower running tests and doing full builds became. I thought it was some issue with the JVM ecosystem. Then I started a project with pure Java and I was blown away by how fast it was. Unit tests in my IDE running as fast as I'm used to in Go. And indeed I was surprised by the speed of the compilation step of the build too. Perhaps Kotlin is doing better now, haven't touched it in a few years, but yeah, Java made some great steps there in the past decades.

Re: Java 26 is here

#222

Post by gf000 »

lucketone wrote: post #70
andyjohnson0 wrote: post #43

Earlier quoted context omitted.

"a solid foundation for the future" is faint praise for a language that has been around for over thirty years. > It has become a best of breed language To me it lags significantly behind .net (runtime) and C#/F# (language). I don't see Java catching-up.

Java is 4th on tiobe. Bright future for it just means it is not planning to become 40th or 400th. (My prediction - in next ten years java will always be among top 6; new language might come to the very top and some leapfrogging game between c# and java)

Tiobe once rated Visual Basic ahead of JS. I would rather believe some future reading octopus than that absolutely useless ranking.

Nonetheless, I agree with your take.

Re: Java 26 is here

#223

Post by oblio »

zadikian wrote: post #103
oblio wrote: post #98

Earlier quoted context omitted.

That's a very shallow argument.

If it were shallow, it'd be easy for them to fix

Backwards compatibility, every vim and emacs and bash enthusiast should know about it.

It's easy for the USER to fix, since there are flags available. In the day of LLMs it's also easy to find out about those flags and what they do. And if it's so important, testing shouldn't be supremely hard, either.

Re: Java 26 is here

#224

Post by gf000 »

mghackerlady wrote: post #189
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…

Java isn't even true OO. The only truly OO programming languages that I know of are SmallTalk, Obj-C, and Ruby

Says a single guy who may have coined the term, but that's not how words work. The industry's millions of devs use it differently, so the de facto meaning is that java is an OOP language, and the original is closer to the actor model.

Re: Java 26 is here

#225

Post by pjmlp »

spockz wrote: post #72
gf000 wrote: post #45

Earlier quoted context omitted.

They trade blows, and have different philosophies (complex runtime, simpler language vs the reverse). E.g. on the GC side Java is ahead of any other platform, especially with the low-latency ZGC garbage collector.

I would love to have a Java compiler with the capabilities of the .net compiler. To make incremental builds to aid code completion including type information, looking past simple syntactical errors, fixing them, and continuing compilation. Currently, this is “magic” embedded in eclipse, IntelliJ, and maybe a bit in the vscode plugin. Imagine having a Java LSP running that can provide all this information while typing…

It also slows VS code a lot, is not properly documented, and still relies on concatenating strings together, due to Source Generators interaction with attributes.

Re: Java 26 is here

#226

Post by gf000 »

HendrikHensen wrote: post #207
zadikian wrote: post #92

Earlier quoted context omitted.

Lack of virtual threads was its biggest remaining problem because this made the common ways of doing cooperative multitasking very ugly. Go's big thing was having that from the start. Maybe now that Java has it too, it's set? Though JS will still have the least boilerplate because of the way it handles types.

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…

Small java programs start up well in the milliseconds.

I don't really think it's fair to compare some old jboss monstrosity doing the job of a whole kubernetes cluster to a dumb hello world server written in go.

Sure, java startup time is and will probably always be worse than putting everything into a single binary - but it is way overblown in many discussions. I have a bunch of Quarkus services on my home server and they start up immediately.

Re: Java 26 is here

#227

Post by gf000 »

HendrikHensen wrote: post #211
deepsun wrote: post #122

Earlier quoted context omitted.

IMO, Kotlin coroutines are better of Go's goroutines, although they are a little different beasts to compare honestly (apples and oranges). Go inits goroutines on stack, but min size is 4KiB, so it's not trivial to grow them. Also you need to watch over and destruct goroutines manually to prevent memory leaks (using var wg = sync.WaitGroup defer wg.wait() wg.Add(1) go func() { defer wg.Done() } ) And create a separat…

Kotlin coroutines don't really exist. They're a (very neat) programming trick to support coroutine-like behavior on the JVM which doesn't support coroutines. If you look at the bytecode it produces, it honestly is a mess. And it colours your functions too: now you have be ever careful that if your function is running in a coroutine, there are certain things you should absolutely avoid doing in that function, or any f…

> Kotlin coroutines don't really exist. They're a (very neat) programming trick to support coroutine-like behavior on the JVM

Well, guess how coroutines are implemented in Rust/C++/everywhere else!

Nonetheless, I do think that java virtual threads are superior for the vast majority of use cases and they are a good default to reach for for "async" like code.

Re: Java 26 is here

#228

Post by EdwardDiego »

HendrikHensen wrote: post #214
EdwardDiego wrote: post #192

Seeing as we're having a $LANG war, after 15 years in JVM land, I moved to a Python / Go shop, and fuck I miss Java. Not so much the language (although modern Java is pretty slick), but the stuff surrounding it. * No typosquatting issues because every package has a group id verified by real humans and DNS TXT records. * JMX as a standardized mechanism of exposing ways to interact with running code / expose metrics. (…

> * No typosquatting issues because every package has a group id verified by real humans and DNS TXT records. While I think this is a huge boon, have you ever published a package on the Maven Central repository? I must confess I haven't in a few years now, but when I did until ~3 years ago it was a major pain in the ass. And every release again. I think there's something to say about Go's model where the package is j…

Yeah, publishing a package is a PITA for the precise reasons of maintaining trust in, and the quality of the packages.

That's why you need documentation to publish to Maven central, that's why your package needs to specify its license, GPG checksum etc.

Yep, it's a lot harder than publishing to Pypi or Cargo, but I'm now firmly of the opinion that it's good that it is. The gates between you and publishing a package are there for deliberate reasons.

> Perhaps you're alluding to the things you can do with JMX

Yep, specifically things like "set the logger org.foo.package.Bla to DEBUG while the app is running", without restarting and without having to add an internal HTTP endpoint to be able to accomplish that. It's just there for free, every JVM logging library and metrics library exposes itself via JMX for that same reason - ease of observability, without restarts, without custom code.

E.g., I can access Kafka client metrics via JMX anytime I like. JConsole will even give me pretty graphs.

If I want them in Prometheus, I run the app with a Java agent that takes those MBean metrics and exports them in Prometheus format on an HTTPS endpoint.

I understand you can accomplish much the same with some internal HTTP endpoints, but that presumes they exist.

If you need them, but that microservice hasn't deliberately exposed them, you need to change the code, and then make a new release, which slows down your ability to diagnose what's going on right now.

In Java, every observability library exposes itself via JMX, all you had to do as a sysop was ensure that the JMX port was open.

Also, the ability to easily observe the metrics of the VM itself via JMX so I can see what's going on with GC in a running app without having to explicitly expose that.

If you suspect a memory leak, or something that should be GC-able isn't, or that there's far too many object allocations occurring that's smashing the first gen portion of the heap and causing excessive GC pauses, the instrumentation to investigate it as your app runs is right there, it's baked into the JVM.

That's why I miss it - the JVM was built to be instrumented and observed by the people running it.

I really wish Golang and everyone else would emulate the Java approach to observable metrics as well as the Java approach to logging and packaging.

There's no shame in stealing the good ideas Java had, but no-one seems to, to my frustration.

Re: Java 26 is here

#229

Post by gf000 »

gib444 wrote: post #102

I wonder what percentage of java code in the world is still java 8, and always will be?

Still a lot, but in absolute terms the majority of Java applications are 8+ for 4-5 years now, according to Oracle's statistics - so they are a minority. It's just that there are so many java projects that it is still a huge number.

Re: Java 26 is here

#230

Post by fingerlocks »

gf000 wrote: post #199
owlstuffing wrote: post #151

Earlier quoted context omitted.

> We now know that we prefer composition over inheritance When people say "composition over inheritance" in Java discussions, they usually mean the trivial modeling rule: prefer has-a over is-a. But that’s not what composition is really about. The deeper idea is interface composition -- building types by composing multiple behavioral contracts behind a single cohesive surface. Java provides inheritance and interfaces…

Well, what mainstream language has better tools for composition?

Rust with traits and Swift with protocols
Post reply on HN