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

101–110 of 178 posts

Re: Java 22 Released

#101

Post by jen20 »

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…

If you consider Go to be "dead on arrival", I don't know what world you're living in.

Re: Java 22 Released

#102

Post by craigacp »

bitwize wrote: post #71
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.

This is exactly what I've been calling the "public static void main problem" for years (and an illustration of why I thought something like BASIC or Python should be everyone's first programming language). Neat to see the Java team come up with a solution for it. But "public static void main" runs deeper, and has to do with immediacy: shortening the time between the programmer giving instructions to the computer and…

Java has had the ability to run a single code file directly by running `java ` since Java 11 - https://openjdk.org/jeps/330. And it's had a Java REPL since Java 9.

Re: Java 22 Released

#103

Post by chungy »

cempaka wrote: post #100
chungy wrote: post #79

Earlier quoted context omitted.

Java 8 allows access to unsafe methods, which despite being meant for internal JDK use only, have been widely used in external projects. Newer Java versions do not permit the use of unsafe except for the JDK itself. It wasn't ever part of the public API that's promised to never break, and JDK developers were annoyed that it being used meant Java got perceived as unstable, and it's gone in more recent versions.

I thought the issue was not Unsafe methods (which are only just now starting to be marked for removal) but rather various bytecode weaving libraries like javassist. As the JDKs progressively enforce bytecode verification more strictly these libraries sometimes run afoul of the new restrictions. (I speak from a little experience here, managed a somewhat involved upgrade path from 7 to 8 way back in the day which had t…

That's probably another factor, and these two aren't the only ones.

Re: Java 22 Released

#104

Post by dajt »

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 doubt that. Java is complicated enough that it's not beginner friendly even if you don't have to write the class to put main into.

Given these are still methods of classes this JEP seems pointless to me. Not having to write class x {} isn't a great time saver.

Re: Java 22 Released

#105

Post by svieira »

AtlasBarfed wrote: post #84
bheadmaster wrote: post #47

Earlier quoted context omitted.

Groovy itself is a bad Groovy.

bad opinion is bad I get gradle is a disaster (but that's more of a poorly managed and evolved DSL problem) But ... does anyone use Spock and think "groovy sucks"? Yeah, I doubt it.

I hate to be "that guy" but ... raises hand.

Spock is also a DSL disaster that's trying to be ScalaTest (https://www.scalatest.org/user_guide/property_based_testing) but in a dynamic language. Every time I use it I have to re-learn the syntax. (I have the same issue with Gradle, so maybe it's just-me?)

Re: Java 22 Released

#106

Post by MichaelMoser123 »

Nullabillity wrote: post #77
preommr wrote: post #46

It's kind of startling to see how many places still use Java 8, estimated at ~1/3 of projects according to a survey i just googled. And something like half that still use java 11.

In practice, Java is the language of legacy and Android. Java 8 keeps working, while "modern" Java keeps chasing mistakes like green threads. If anything, I'm more baffled by 9+ having a non-neglegible market share at all.

you didn't like java generics? why?

Re: Java 22 Released

#107

Post by marginalia_nu »

AtlasBarfed wrote: post #83
ulrikrasmussen wrote: post #59

Earlier quoted context omitted.

How so? I don't think there are many good things to say about Groovy, but I generally agree with most new features introduced to Java. What do you think Groovy does better?

- String interpolation - triple-quote strings / blocks - minimal class boilerplate (this posting) - closures (Java closures are worse IMO) - usable hashbang for UNIX - I think java has strings in switch now, don't they? Do they have expressions? WAIT, does Java STILL force you to write getter/setters?

But Java has all those features...?

Re: Java 22 Released

#108

Post by marginalia_nu »

chungy wrote: post #79
fngjdflmdflg wrote: post #76

Earlier quoted context omitted.

Wasn't the whole point of Java never releasing a 2.0 that there would never be breaking changes? Seems like something went very very wrong with Java if the state they are in is that the language refuses to make breaking changes and the developers refuse to take up the supposedly non breaking updates due to breaking changes based on the comments I'm seeing here. So the language never improves as much as it can and the…

Java 8 allows access to unsafe methods, which despite being meant for internal JDK use only, have been widely used in external projects. Newer Java versions do not permit the use of unsafe except for the JDK itself. It wasn't ever part of the public API that's promised to never break, and JDK developers were annoyed that it being used meant Java got perceived as unstable, and it's gone in more recent versions.

Huh, but I'm using Unsafe in JDK 21?

Re: Java 22 Released

#109

Post by blackoil »

sireat wrote: post #58
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.

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.

Re: Java 22 Released

#110

Post by temporarely »

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…

Kilim was the first for Java iirc.

Interesting point regarding scheduler and the interruptibility of FFI calls. Just thinking about it I don't see how this can be addressed. So definitely interested in learning here: what is the remedy to your criticism here beyond "document behavior"?

Post reply on HN