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

Java 21: The Nice, the Meh, and the Momentous

horstmann.com

Post reply on HN
Print view View original

161–170 of 191 posts

Re: Java 21: The Nice, the Meh, and the Momentous

#161

Post by riku_iki »

pron wrote: post #159
riku_iki wrote: post #155

Earlier quoted context omitted.

I read materials, and my opinion is that virtual threads is hyped mess which adds very little benefits (or maybe doesn't at all) in very few use cases, but will bring more complexity and fragmentation into platform: - 95% java business spaghetti code doesn't require such scalability and fine with spawning of 10k threads on modern hardware - in 5% left cases, 80% can be covered by executorservice and forkjoinpool - in…

I don't know what relevant performance issues you're referring to, but if you want to learn more about concurrency and performance, I suggest you start with some of the basics of the theory behind concurrent servers: https://youtu.be/07V08SB1l8c As I said, I've put examples and detailed explanations in a significant amount of material that's available online that will help you understand how and why user mode threads…

> While I can't teach concurrency and the design of the Java platform

my point is that you can't teach because you don't have expertise and getting lost on extremely basic things: https://news.ycombinator.com/item?id=37620046

Re: Java 21: The Nice, the Meh, and the Momentous

#162

Post by NovaX »

krzyk wrote: post #140
NovaX wrote: post #95

Earlier quoted context omitted.

Kotlin, not Groovy, has been the culprit for slower Gradle support. I believe there was some split module pain in Groovy wrt Java 9, but it has been very smooth since then. The Kotlin compiler on the other hand is not very forgiving. This is a moot point because your the build execution and the project compile/run can be on different JDKs. It is a tiny amount of configuration to decouple them, e.g. to use an EA build…

Yeah, you are right that decoupling build tool JDK and compile JDK is the way to go. But Groovy does indeed not work, or has support very late for releases between 8, 11, 17 and 21 - so for anyone that wants to stay current (and not wait 3 or 2 years), using groovy in your code will be a pain - that might be also possible for other JVM languages, but I don't know, haven't used them.

Oh interesting. Typically the gradle release notes, like 8.4-rc-1, will have comments that imply that Groovy build scripts compile but Kotlin ones lag.

"Gradle now supports using Java 21 for compiling, testing, and starting other Java programs. This can be accomplished using toolchains. Currently, you cannot run Gradle on Java 21 because Kotlin lacks support for JDK 21. However, support for running Gradle with Java 21 is expected in future versions."

https://docs.gradle.org/8.4-rc-1/release-notes.html#support-...

Re: Java 21: The Nice, the Meh, and the Momentous

#163

Post by riku_iki »

kaba0 wrote: post #128
riku_iki wrote: post #102

Earlier quoted context omitted.

yes, you shouldn't add blocking code into executorservice..

Wtf, where on Earth do you put blocking code then? Firing off some long-running task in a background thread through executors is bog-standard usecase.

discussion was about specific context: avoiding overhead from spawning millions of threads, in this case you shouldn't have any blocking code at all, all API should utilize epoll underneath or something similar.

Re: Java 21: The Nice, the Meh, and the Momentous

#164

Post by kaba0 »

riku_iki wrote: post #163
kaba0 wrote: post #128

Earlier quoted context omitted.

Wtf, where on Earth do you put blocking code then? Firing off some long-running task in a background thread through executors is bog-standard usecase.

discussion was about specific context: avoiding overhead from spawning millions of threads, in this case you shouldn't have any blocking code at all, all API should utilize epoll underneath or something similar.

And where do you handle callbacks?

Re: Java 21: The Nice, the Meh, and the Momentous

#165

Post by Brystephor »

belfthrow wrote: post #105
Brystephor wrote: post #26

Earlier quoted context omitted.

1) dependencies need to be upgraded. for example, not all versions of Gradle support all Java versions. So you need to upgrade Gradle to upgrade Java. 2) other things are deemed to have higher priority. 3) people are satisfied with existing features and don't want to spend energy to upgrade to something that doesn't provide immediate value. 4) folks aren't educated on what the benefit of switching would be so why wou…

1) is garbage. Since grade 6 you can run on 22 ea with no issues. Use toolchains, as they say on their docs. 2) no shit. What business user is every in their mind prioritising upgrading their language version? It's not up to them to push the upgrade. It's yours. 3) of course they are. People don't desire what they don't want. Invest in people who are actually interested in improvement of their software. 4)the java te…

1) you're assuming every one is on Gradle 6 or higher lol. I can assure you that is not true.

2) Sure, pushing and making the decision are not the same thing. I can complain and persuade as much as possible and it doesn't mean it's going to happen.

3) I agree that you want people who care about improving software. Upgrading language versions isn't always the best route to do that though.

4) I don't think everyone on the team is reading about the latest updates in the world of Java. I think a pretty small portion of engineers are keeping 100% up to date, following Twitter accounts for Java dev, watching YouTube videos on it, etc. All that is educational and that's great to know but for most people, it's not going to help them work better because they know about features they can't use.

5) definitely sounds aggressive but okay. I haven't found a company yet who's complained about working in Java 8 versus 11/17. If a company is hiring for a role that uses Java, they're likely not limiting their candidates to those who've used their version of Java. It's a pretty standard language and if you know any other object oriented language, you'll be fine.

Re: Java 21: The Nice, the Meh, and the Momentous

#166

Post by Brystephor »

vips7L wrote: post #145
Brystephor wrote: post #26

Earlier quoted context omitted.

1) dependencies need to be upgraded. for example, not all versions of Gradle support all Java versions. So you need to upgrade Gradle to upgrade Java. 2) other things are deemed to have higher priority. 3) people are satisfied with existing features and don't want to spend energy to upgrade to something that doesn't provide immediate value. 4) folks aren't educated on what the benefit of switching would be so why wou…

You’re just delaying and making the upgrade worse when the time comes. It’s much easier to upgrade now to 11 and then 17 and then 21 rather than try to upgrade from 8 to 27 when 8 is finally EOL. Whether you perceive there to be no immediate benefit (hint: there is, Java 8 is an antiquated runtime) or not, delaying upgrading until Java 8 EOL is a way larger risk than upgrading now.

I've never done a language upgrade. I don't know what it takes. I've heard 8->11 is painful and 11->17 is not. So doesn't that mean jumping from 8->17 directly is mostly the same as going from 8->11?

I'm not saying there is no benefit. I'm not saying there is no risk. I agree that going from 8->17 would be worse than 8->11->17.

My point is to list out reasons why a team may not be able to just spend a day upgrading (dependency issues) or why someone might not be given the time to do it.

Re: Java 21: The Nice, the Meh, and the Momentous

#167

Post by riku_iki »

kaba0 wrote: post #164
riku_iki wrote: post #163

Earlier quoted context omitted.

discussion was about specific context: avoiding overhead from spawning millions of threads, in this case you shouldn't have any blocking code at all, all API should utilize epoll underneath or something similar.

And where do you handle callbacks?

there are tons of variations, depending on your logic and API. The closest to virtual threads is ForkJoinPool and RecursiveTask, where you can have code like regular blocking code:

var f = async_api_returns_future();

...

var res = f.join();

but join() won't block OS/JVM thread, but make it to perform other tasks in the queue.

Or you can design API which will receive executorService as params, and run callback there, e.g.:

async_call(Callable callback, ExecutorService threadPool);

Re: Java 21: The Nice, the Meh, and the Momentous

#168

Post by munificent »

brabel wrote: post #118
munificent wrote: post #98

Earlier quoted context omitted.

We require "var" before variable patterns because we also allow named constants in patterns (which match if the value is equal to the constant's value): const pi = 3.14; // Close enough. switch (value) { (pi, var pi) => ... } This case matches a record whose first field is equal to 3.14 and binds the second field to a new variable named "pi". Of course, in practice, you wouldn't actually shadow a constant like this,…

I don't find symbols to be pointless. They are useful as "interned strings" and that's exactly what I need sometimes. I could use `const myThing = "my thing";` for that purpose (but with symbols I don't need to declare it anywhere, just use it... for better or worse!), I suppose, but before `const` existed, I believe symbols were the only way to do that?

> They are useful as "interned strings" and that's exactly what I need sometimes.

I'm not sure exactly what you mean by "need" here, but as far as I know, Dart doesn't make any promises about the memory management or efficiency of either strings or symbols.

If I were you, I'd just use strings.

Re: Java 21: The Nice, the Meh, and the Momentous

#169

Post by nvm0n2 »

riku_iki wrote: post #161
pron wrote: post #159

Earlier quoted context omitted.

I don't know what relevant performance issues you're referring to, but if you want to learn more about concurrency and performance, I suggest you start with some of the basics of the theory behind concurrent servers: https://youtu.be/07V08SB1l8c As I said, I've put examples and detailed explanations in a significant amount of material that's available online that will help you understand how and why user mode threads…

> While I can't teach concurrency and the design of the Java platform my point is that you can't teach because you don't have expertise and getting lost on extremely basic things: https://news.ycombinator.com/item?id=37620046

Are you aware you're talking to the guy who added virtual threads to the JVM? Disagree on design if you wish, but the idea he isn't an expert in these matters is a bit silly.

Re: Java 21: The Nice, the Meh, and the Momentous

#170

Post by riku_iki »

nvm0n2 wrote: post #169
riku_iki wrote: post #161

Earlier quoted context omitted.

> While I can't teach concurrency and the design of the Java platform my point is that you can't teach because you don't have expertise and getting lost on extremely basic things: https://news.ycombinator.com/item?id=37620046

Are you aware you're talking to the guy who added virtual threads to the JVM? Disagree on design if you wish, but the idea he isn't an expert in these matters is a bit silly.

He is person on salary in oracle, which is not top tier tech company. There are tons of virtual threads like frameworks were implemented in JVM and in other languages, looking at his github profile he has 5 years experience in working on this thread stuff, before that he worked on some bloated j2ee stuff, all of these doesn't qualify for some unconditional authority, so I judge him base on his expertise demonstrated in this discussion, which looks very weak.
Post reply on HN