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

Java 22 Released

mail.openjdk.org

Post reply on HN
Print view View original

141–150 of 178 posts

Re: Java 22 Released

#141

Post by Shakahs »

okeuro49 wrote: post #140
jimbokun wrote: post #33

Maybe my favorite feature in this release: https://openjdk.org/jeps/463 Finally solves the inscrutable Hello World program! Yes, it's just ergonomics for early beginners. But could be the difference in whether or not someone new to programming sticks with Java or not.

I really dislike this feature. It's better to just say "we will come to this concept later", rather than make a fake syntax that does this (taken from the JEP) behind the scenes: new Object() { // the implicit class's body }.main(); It adds more confusion, as you are left explaining that you could not really run an instance method without instantiating the class -- it was just something fake for beginners.

I agree. Coming from NodeJS I appreciate how explicit Java is. The complexity is there either way, but in Java it's right up front where I can see it, not hidden away under layers of abstraction for a supposedly better DX.

Re: Java 22 Released

#142

Post by thisislife2 »

Now this may seem like a silly question, but if I only want to run Java apps on macOS, what should I install from MacPorts? Searching for "JRE" gives no results. Searching for OpenJDK gives various options including:

- OpenJDK21: https://ports.macports.org/port/openjdk21/details/ , - openjdk21-zulu: https://ports.macports.org/port/openjdk21-zulu/details/ - openjdk21-oracle: https://ports.macports.org/port/openjdk21-oracle/details/

each of them having so many variants (see the links). What variant needs to be installed to just run a Java app?

Re: Java 22 Released

#143

Post by ezst »

blackoil wrote: post #109
sireat wrote: post #58

Earlier quoted context omitted.

Actually a nice feature. This solves the public static void main string args issue. Still if I need JVM then Scala or Kotlin are still preferable over Java. Obligatory Java for the Haters in 100 Seconds: https://www.youtube.com/watch?v=m4-HM_sCvtQ

> Still if I need JVM then Scala or Kotlin are still preferable over Java. That's so 2010. I would avoid Scala like plague. It is a soup of all features imagined and some more. Java is difficult for novice. With Scala even experienced senior devs can look into a snippet and be befuddled. It is designed by academicians who thought clever looking choice is better.

About a decade ago, some Scala library authors thinking that "everything is better as a DSL" gave Scala a reputation for being a hieroglyphics soup, but that cannot be farther from the truth today. It's a really nice language to learn and to use, and the only one in my experience that I would want to take with me to scale from a quick dozen-liner script bash-style to a highly concurrent, highly available server application, from native to jvm to JS.

And the foothold in academics has some practical perks, too, like a sound type system (DOT calculus), compatibility guarantees at a theoretical level (TASTy), and what's cooking in the area of capture checking might be a general solution to many of the industry's biggest challenges (e.g. colorless asynchronous programming, safe errors, safe resource management, ... Think of Rust's borrow checker as a special case of this, and the consequences for scala-native as a systems programming platform).

Re: Java 22 Released

#144

Post by mike_hearn »

thisislife2 wrote: post #142

Now this may seem like a silly question, but if I only want to run Java apps on macOS, what should I install from MacPorts? Searching for "JRE" gives no results. Searching for OpenJDK gives various options including: - OpenJDK21: https://ports.macports.org/port/openjdk21/details/ , - openjdk21-zulu: https://ports.macports.org/port/openjdk21-zulu/details/ - openjdk21-oracle: https://ports.macports.org/port/openjdk21-o…

Usually Java apps come with Java these days, like how there's no independent way to run Electron apps, it just comes with the download of the app itself. There are tools that make it easy like jpackage and (toots my own horn) https://www.hydraulic.dev

If you want to just quickly run a fat jar then any will work. "openjdk21" is fine. The Zulu variant comes with JavaFX which simplifies things if your app needs that.

Re: Java 22 Released

#145

Post by jonathanlydall »

lotsoweiners wrote: post #42
jimbokun wrote: post #33

Maybe my favorite feature in this release: https://openjdk.org/jeps/463 Finally solves the inscrutable Hello World program! Yes, it's just ergonomics for early beginners. But could be the difference in whether or not someone new to programming sticks with Java or not.

That sounds a lot like Top-level Statements in the .Net world. Personally I don’t use that feature because I’m old and get confused if things are magic but can certainly see the benefit for the newer devs.

I’m also a somewhat old school C# dev and the main reason I don’t use top level statements is that they only work in a single file of an application, so that single file is different from every other file in your solution.

It’s okay if you’re only writing a single file, and it really seems intended for beginners or micro applications, but for those of us writing anything besides the most trivial, it’s merely “cute” and just adds inconsistency.

Re: Java 22 Released

#146

Post by zbentley »

oaiey wrote: post #9

Foreign Function Interface is one of the key advantages what C# had over Java (e.g. against huge APIs like Android or macOS). I am really curious how this JEP turns out.

It's definitely exciting and a big step forward from JNI/JNA.

However, I am a little concerned about the heavy emphasis on library unloading in the JEP. Unloading is famously fraught and unsafe for wide swaths of common libraries ... or maybe I'm overfitting due to recent trauma[1] and everything will be fine.

1. https://gist.github.com/thomcc/8c4a8003cf1a282949a539e899cb4...

Re: Java 22 Released

#147

Post by zbentley »

Nullabillity wrote: post #98
citrin_ru wrote: post #80

Earlier quoted context omitted.

> Java keeps chasing mistakes like green threads If by green threads you mean virtual threads in JDK 21 could you please elaborate why they are a mistake? I'm not a Java developer but from what I see new concurrency model allows to write much more efficient network software - OS threads are expensive (in terms of RAM/CPU) and to handle many thousands of network connections (C10k problem) you have to either throw a lo…

There were already "user-mode" implementations of asynchronicity on the JVM for years (like Monix, cats-effect, Pekko (fka Akka), etc). Loom has a worse API, is hidden from the user (what's preemptible and what will cause OS thread starvation? who knows!), and effectively ends up infecting the whole JVM with its complexity. Go shares most of those downsides, but as a greenfield project (..heh) there's at least the ex…

> Go shares most of those downsides

Does it? Preemptability is pretty robustly solved in Go. While it's sometimes less efficient than I'd like, it's a far cry from the initial draft of virtual threads in java where a misplaced "synchronized" could sneakily starve entire executors. Even with CGo pinning (which, as you indicate, is rare due to the bulk of pure-Go libraries) I'm having trouble thinking of reasonable situations where full starvation or deadlock occurs rather than (admittedly unpleasant!) latency and queueing.

That said, Loom is quite new and deliberately iterative in approach, and the Java core folks are quite skilled, so I do expect to see substantial improvements in behavior and issue-detection tooling here over the coming years.

> I'd consider all three implementations of the approach to be dead on arrival

I'd argue that eventlet/greenlet failed for different reasons than the concurrency model or starvation risk (the monkeypatching approach just can't sustainably work in an ecosystem as big and native-code-dependent as Python's), hence Python's falling back to traditional async/await cooperative concurrency.

The Rust folks are struggling with the same choices here as well, further constrained by their requirements of a GC-less runtime with near-zero-overhead C FFI, which precludes them from using Go's approach. There was some great discussion of that here: https://news.ycombinator.com/item?id=39242962

Re: Java 22 Released

#148

Post by DarkNova6 »

owlstuffing wrote: post #64
DarkNova6 wrote: post #50

Earlier quoted context omitted.

Boring changes like these are what keeps Java interesting. New and shiny syntax sugar becomes stale real quick.

As a modern language Java is still quite feature deficient. But you can use compiler plugins like the manifold project[1] to level up. 1. https://github.com/manifold-systems/manifold

I'm not 100% sold. I like some of it's features (e.g. the mentioned typed SQL safety) but adding all of it seems super heavy-weight. Lombok took a good time to become widely accepted and I don't think this will ever appeal to more than just a niche audience.

At the very least, I prefer not to have any surprises in my codebase because it looks like Java but isn't quite so really.

Re: Java 22 Released

#149

Post by MBCook »

kaba0 wrote: post #120
MBCook wrote: post #89

Earlier quoted context omitted.

Oh that’s right. My company didn’t want to pay the insane Oracle fees to keep getting support. I think it wasn’t even a discussion once the saw the number, but that’s basically a rumor. So we have to stick to OpenJDK which means 8 doesn’t receive security updates and is untenable.

Seems like willful incompetence on the company’s part. Just for note, JDK 8 came from the same time as Windows XP . Sure, the attack surface is different, but if they have no plans on moving forward and doesn’t even want to pay for support, then frankly fck them. Then they just surprise pikachu when a bunch of their user data leaks.

That seems oddly hostile.

We moved to the latest LTS. Continuing to use an old version with no security updates would be moronic. Of course we didn’t do that.

All I was saying was sticking with 8 wasn’t tenable for financial reasons.

Re: Java 22 Released

#150

Post by krzyk »

cryptos wrote: post #125
krzyk wrote: post #29

Linkable features https://openjdk.org/projects/jdk/22/ For me personally the most interesting one is JEP461 (Stream Gatherers) https://openjdk.org/jeps/461 This will allow addition of interesting stream operations.

This is indeed nice. However, static extension methods would have made this feature simpler (and more generic).

And would also make code harder to read. I was always reluctant to use those in Scala because of this.
Post reply on HN