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

141–150 of 191 posts

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

#141

Post by rusk »

frou_dh wrote: post #130
rusk wrote: post #31

Earlier quoted context omitted.

In Python you can terminate a for loop with else, which will be run whenever the loop runs to the end without breaking

That's not particularly relevant to the nice pattern matching property I mentioned. If you need to manually write supplementary code to get the exhaustiveness safety then that's back into the realm of bog-standard defensive programming. Here's what I mean. The Ruby will throw NoMatchingPatternError and the Python will silently do nothing. x = [10, "figs"] case x in [n, "apples"] :foo in [n, "oranges"] :bar end # ---…

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

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

#142

Post by twic »

winrid wrote: post #114
za3faran wrote: post #110

Earlier quoted context omitted.

Do you have a citation for that? Genuinely curious.

The stack for the VT requires a heap allocation [0], which ok, not huge deal for most scenarios, but something to consider. Reactive programming will avoid that. For example, for a service that doesn't do much IO (like an in memory pubsub thing or CDN) you would still want to use reactive programming if you care about performance, since likely the code will be simple anyway. [0] https://openjdk.org/jeps/444

I'd definitely be interested to see some benchmarks of real-world code, once virtual threads and its attendant web frameworks have had a year or two to mature.

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

#143

Post by frou_dh »

rusk wrote: post #141
frou_dh wrote: post #130

Earlier quoted context omitted.

That's not particularly relevant to the nice pattern matching property I mentioned. If you need to manually write supplementary code to get the exhaustiveness safety then that's back into the realm of bog-standard defensive programming. Here's what I mean. The Ruby will throw NoMatchingPatternError and the Python will silently do nothing. x = [10, "figs"] case x in [n, "apples"] :foo in [n, "oranges"] :bar end # ---…

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.

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

#144

Post by jfengel »

brnt wrote: post #113
jfengel wrote: post #44

Earlier quoted context omitted.

The bigger the project, the more painful the upgrade. Package systems are convenient to avoid reinventing the wheel, until you have to upgrade any piece of it. Then you're stuck trying to figure out which versions of each package go together. If Package A won't run on JDK 17 your entire project is stuck on JDK 11. If Package B is upgraded but has conflicts with Package A, you have to dig through old versions until yo…

Java isn't forward compatible?

Overwhelmingly it is, until it isn't. There are tiny gotchas, especially if you play with some of the murkier aspects, such as reflection or class loading.

The more of someone else's code you use, the more likely one of them bumps into one of the gotchas. And that sets off a cascade of conflicting versions.

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

#145

Post by vips7L »

Brystephor wrote: post #26
larperdoodle wrote: post #21

Earlier quoted context omitted.

Why haven't places updated already? It's not that much work to update. Where I work we always go to the new LTS version as soon as it's supported by gradle. Doesn't cross anyone's mind to _not_ upgrade.

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.

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

#146

Post by vips7L »

winrid wrote: post #114
za3faran wrote: post #110

Earlier quoted context omitted.

Do you have a citation for that? Genuinely curious.

The stack for the VT requires a heap allocation [0], which ok, not huge deal for most scenarios, but something to consider. Reactive programming will avoid that. For example, for a service that doesn't do much IO (like an in memory pubsub thing or CDN) you would still want to use reactive programming if you care about performance, since likely the code will be simple anyway. [0] https://openjdk.org/jeps/444

But what’s more expensive, some more ram? Or the hours upon hours upon hours wasted in dev salaries trying to develop and debug reactive code?

Also is that VT allocation more than all of the extra allocations from reactive frameworks internally? Or all of the heap capturing lambdas that you pass to reactive libraries? Do you have a source comparing any of this?

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

#147

Post by owlstuffing »

unregistereddev wrote: post #3
ecshafer wrote: post #2

Java getting better pattern matching is a great change. Id really like more of the functional features to make it into Java. I would love if Java pattern matching could at least get to the level of ruby pattern matching. Ruby pattern matching will allow you to deconstruct arrays and hashes to get pretty complicated patterns, which is really powerful. Right now it seems like Java might have that with a lambda in the p…

Pattern matching is a neat tool to keep in the toolbox. When it's the right tool for the job, it is really cool and is a lot cleaner than a bunch of conditional checks. However, I rarely reach for it. Maybe my use cases are unusual? I am genuinely curious how often other developers find pattern matching to be the best tool for the job.

Patterns are somewhat nice to have, but for me they’re difficult to read, and not because my brain isn’t used to them. The simple identifier instanceof is about all I’ll use _most_ of the time. Otherwise, yes they are more concise, but lose too much information in the process.

I’d rather see a boatload load of other features before patterns. I’ve been experimenting with project manifold[1]. _That_ is the path Java sb on. Just my take.

1. https://github.com/manifold-systems/manifold

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

#148

Post by vips7L »

rr808 wrote: post #103
hinkley wrote: post #58

What's the Scala community think about this development? I would think this would affect them quite a lot. Google is not helping.

Scala community always thinks they're the best tool. The size of the community is at best static though, Kotlin and re-energized Java took away most of the reasons for using it. I know in my company the teams that went the Scala route complain of huge compile times and really struggle to find people, I think we'll probably port back to Java.

Scala is just too complex, the tooling too slow, and the community had way too many breaking changes.

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

#149

Post by riku_iki »

pron wrote: post #137
riku_iki wrote: post #102

Earlier quoted context omitted.

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

Then you either don't get the same scalability that virtual threads give you or you get it but with asynchronous code that requires not just more work but can't enjoy the same observability/debuggability on the Java platform.

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

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

#150

Post by pron »

riku_iki wrote: post #149
pron wrote: post #137

Earlier quoted context omitted.

Then you either don't get the same scalability that virtual threads give you or you get it but with asynchronous code that requires not just more work but can't enjoy the same observability/debuggability on the Java platform.

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 must reach for an asynchronous composition DSL (such as the one offered by CompletableFuture) which is not as composable as the basic language primitives.

Moreover, the platform now has no insight about your composition. Exceptions, which are designed to give context in the form of a thread stack trace, simply don't know about the context as it's not composed through the normal composition (in plain terms, stack traces in asynchronous code don't give you the operation's context). Debuggers cannot step through the asynchronous flow because the platform's built in debugging support works only by stepping through threads, and profilers are no longer able to assign IO to operations: a server that's under heavy load may show up as idle thread pools in a profiler because the platform cannot assign an asynchronous operation to some asynchronous pipeline such as CompletableFutures because these are not observable constructs of the Java platform.

Virtual threads give you the same scalability as asynchronous code but in a way that fits with the design of the Java platform. All language constructs work and compose well, debuggers step through code, and profilers can understand what's going on.

That's not to say that some other platform could not be designed around a different construct, but the Java platform -- from language, through libraries and bytecode, and all the way to the VM and its tooling interfaces -- was designed around the idea that sequential composition occurs by sequencing operations on a single thread. And virtual threads are just Java threads.

Post reply on HN