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

151–160 of 191 posts

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

#151

Post by riku_iki »

pron wrote: post #150
riku_iki wrote: post #149

Earlier quoted context omitted.

could you give example what requires more work exactly and where virtual threads give more "observability"?..

Sure. Because handling server requests typically requires IO, if you wish not to block you need some way to sequence operations that is different from the ordinary sequential composition of the language (beforeIO(); blockingIO(); afterIO()). Similarly, other language constructs that build on top of basic sequential composition -- loops, exceptions, try/finally -- no longer work across the IO boundary. Instead you mus…

I am not certain many of your assessments are correct. If you give specific simple example of code, we can iterate there.

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

#152

Post by pron »

waynesonfire wrote: post #18

> Over 10,000 bug fixes Most of which were likely introduced during new feature development in recent releases. To suggest that this on its own somehow manifests a more stable jdk compared to some ancient, battle tested version of the jdk is debatable. I find it rather concerning that so many bugs exist to begin with. Why are these not caught sooner? Has the whole world gone crazy? Am I the only one around here who g…

While you're right that the number of bugs is not very meaningful and most are probably work on brand new features, but bugs in old features are always first fixed in the current version, and then only a subset of them (usually a small subset) is backported to old releases, and regressions are not common.

As to why some bugs go unnoticed for long, if you look at the bug database for reports of bugs that have been effect for a long while you'll see that these are almost always rather extreme corner cases (or, more precisely, the more utilised a mechanism is, the more extreme would be its old bugs). That's simply because full coverage is simply infeasible for software of such size (~8MLOC); you see similar bug numbers for the Linux kernel. The largest software that can be shown to be free of bugs is currently on the order of 10KLOC, so if your software is much larger than that and isn't getting many bug reports it's probably because it's not used that much.

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

#153

Post by pron »

riku_iki wrote: post #151
pron wrote: post #150

Earlier quoted context omitted.

Sure. Because handling server requests typically requires IO, if you wish not to block you need some way to sequence operations that is different from the ordinary sequential composition of the language (beforeIO(); blockingIO(); afterIO()). Similarly, other language constructs that build on top of basic sequential composition -- loops, exceptions, try/finally -- no longer work across the IO boundary. Instead you mus…

I am not certain many of your assessments are correct. If you give specific simple example of code, we can iterate there.

You can find more information, including some examples, in our virtual thread JEP [1] and adoption guide [2].

We did spend some time contemplating teaching the platform about non-thread-based, i.e. asynchronous sequential composition, in the end we realised that if it walks like a thread and quacks like a thread, we might as well call it a thread.

If you read the JEP and play around with virtual threads (e.g. do asynchronous IO with CompletableFuture or blocking IO in a virtual thread and see what their exception stack traces look like and what their JFR profile looks like) you'll quickly see that the capabilities they offer were simply not attainable by asynchronous code, which is why we've spent years to teach the JVM's innermost mechanisms to be able to observe virtual threads and expose them to observability tools the same way as platform threads are (and how I know those capabilities weren't available before).

We've written and presented a significant amount of published material about virtual threads so there's not much point in recreating it here, but if you're interested, all that material is out there.

[1]: https://openjdk.org/jeps/444

[2]: https://docs.oracle.com/en/java/javase/21/core/virtual-threa...

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

#154

Post by ivan_gammel »

Macha wrote: post #134
ivan_gammel wrote: post #123

Earlier quoted context omitted.

When using Spring Boot you usually update just one version and everything else is updated via BOM. There should be a really good reason to have fine-grained control over every single dependency.

Not every app using Spring is using Spring boot

You don’t have to use its functionality to use its BOM.

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

#155

Post by riku_iki »

pron wrote: post #153
riku_iki wrote: post #151

Earlier quoted context omitted.

I am not certain many of your assessments are correct. If you give specific simple example of code, we can iterate there.

You can find more information, including some examples, in our virtual thread JEP [1] and adoption guide [2]. We did spend some time contemplating teaching the platform about non-thread-based, i.e. asynchronous sequential composition, in the end we realised that if it walks like a thread and quacks like a thread, we might as well call it a thread. If you read the JEP and play around with virtual threads (e.g. do asyn…

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 1% cases which left, engineer made wrong decision in choosing JVM because of its other many performance issues

The fact that you can't bring simple code example and quality of your previous comments make me think that you not necessary understand what are you doing.

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

#156

Post by rusk »

frou_dh wrote: post #143
rusk wrote: post #141

Earlier quoted context omitted.

You can use ‘case _’ in that case … it’s not a big deal to opt into this default behaviour.

I know, that's why I mentioned the manual part. What I'm getting from this exchange is that Python is your team and no criticism can be allowed to stand.

No I’m just trying to add substance to the discussion.

I like Ruby but I wouldn’t use it for the things I use Python for.

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

#157

Post by Macha »

ivan_gammel wrote: post #154
Macha wrote: post #134

Earlier quoted context omitted.

Not every app using Spring is using Spring boot

You don’t have to use its functionality to use its BOM.

So honestly I didn't realise that it's POM extended to ecosystem libraries beyond Spring's own. However, it still doesn't solve the problem that e.g. the hibernate version compatible with Spring Framework n+1 is not compatible with the hibernate version compatible with Spring Framework n and now you're doing an "all or nothing" upgrade, which for a large app can be time consuming.

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

#158

Post by brabel »

krzyk wrote: post #124
brabel wrote: post #119

Earlier quoted context omitted.

If you're upgrading every minor Java version, then yeah, I agree Groovy and most other dependencies that may not work on Java version changes off the bat (Lambok, probably Spring and other heavy frameworks like Micronaut and Quarkus, build tools like Gradle... many more) are going to slow you down. You end up with a very simple project if you remove all of that, which is actually a good thing if you can afford doing…

Those are not minor versions, that's quite natural path and is supported by every lib we used, except groovy. And this is the encouraged path for JDK upgrades, people are lazy, but not us :) Spring supports new JDK release ("minor version" like you called them, those between 11 and 17 and 21) before release. The only exception was with JDK 13, there was about 2 week slip there. Lombok (I don't like it) supports every…

I see your point... I've never upgraded to the non-LTS Java versions (almost no one is doing it - as you can see in any survey about it - which in itself is enough for me not to be the "brave" one doing it!) so I don't know how much pain that would've been. To me that just shows that Groovy could do with a bit more attention as I find it to be a great language, specially with Spock... it has made our tests so much nicer. It does have some warts but those are mostly a result of the lack of attention it receives, unfortunately, not some fundamental issues with the language.

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

#159

Post by pron »

riku_iki wrote: post #155
pron wrote: post #153

Earlier quoted context omitted.

You can find more information, including some examples, in our virtual thread JEP [1] and adoption guide [2]. We did spend some time contemplating teaching the platform about non-thread-based, i.e. asynchronous sequential composition, in the end we realised that if it walks like a thread and quacks like a thread, we might as well call it a thread. If you read the JEP and play around with virtual threads (e.g. do asyn…

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 work and why we decided to add them to Java. While I can't teach concurrency and the design of the Java platform from the ground up (especially detailed mechanisms such as stack walking, JVM TI and JFR) on an individual basis on social media, I'd be happy to answer any specific questions you may have once you've familiarised yourself with the subject.

Post reply on HN