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

https://horstmann.com/unblog/2023-09-19/index.html

by pwpwp • 3 years ago

279 185 3 years ago

ecshafer2• 3 years ago

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 pattern, but its not going to be as elegant as ruby where:

case {name: 'John', friends: [{name: 'Jane'}, {name: 'Rajesh'}]} in name:, friends: [{name: first_friend}, *] "matched: #{first_friend}" else "not matched" end #=> "matched: Jane"

But the big change here is virtual threads which should be a game changer.

unregistereddev• 3 years ago

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.

bcrosby953• 3 years ago

It probably depends on the language you're using. Pattern matching is awesome in Erlang and Elixir. In most other languages it ranges from "nice" to "bleh".

Jtsummers3• 3 years ago

When available, I pretty much always use pattern matching. It tends to shorten code while not reducing clarity (often increasing it) which means fewer opportunities for errors to creep in. Statically typed languages that can detect incomplete case handling also reduces the chances for some errors (as long as you don't make a catch-all case) but also helps when you change something so that a new case is needed. It also tends to shift the code to the left, reducing the indentation. So shorter, clearer, less unnecessary indentation. Generally a positive.

weatherlight• 3 years ago

In languages that have strong support for pattern matching, whether it be on values or types, I find myself reaching for it instead of conditionals. It's all about the explicitness for me. You have to list out all the cases you care about, so there's no room for ambiguity. Plus, the compiler will usually warn you if you've missed a case, which is like a built-in bug catcher. It's also great for working with immutable data, less state to worry about. And let's talk about readability; the code basically documents itself because you can see the shape of the data right in front of you. You can even destructure data on the fly, pulling out exactly what you need. If you're using a statically-typed language, pattern matching adds an extra layer of type safety. And, not to forget, it nudges you toward a more functional style of coding, which I find leads to cleaner, more modular code. So yeah, I reach for pattern matching quite a bit; it often feels like the right tool for the job.

ecshafer2• 3 years ago

I think that you can replace almost any If else with pattern matching. Pattern matching makes type checks easier, which if you are really heavily using types through your program, makes pattern matching even better.

hibikir• 3 years ago

Pattern matching is what makes sum types ergonomic enough to be used. Many a Java design doesn't use said interface-based sum types because it's so cumbersome to use them. But whena language has pattern matching, then suddenly designing with sum types in mind is done a lot, and therefore you see examples of good pattern matching everywhere.

When I teach Scala, a very high percentage of the teaching time is ultimately down to re-introducing how to design business domains, because seasoned devs just reach for large classes with a million optional fields, which not only can represent valid systems states, but thousands of invalid ones.

grumpyprole• 3 years ago

One example for you: anytime you needed to use the "Visitor pattern" to do a transformation from one representation to another - you don't need it now. Sealed classes and pattern matching will be more succinct and easier to reason about.

owlstuffing• 3 years ago

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

frou_dh3• 3 years ago

I really like that Ruby throws NoMatchingPatternError if none of the patterns match. It's a bit like the much-acclaimed exhaustive pattern matching in static languages (though at runtime rather than compile-time, obviously) and better than just silently falling off the end, which IIRC is what Python's pattern matching does.

rusk4• 3 years ago

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

brightball• 3 years ago

Simple solution: JRuby.

Virtual threads are going to make Ruby fibers work properly for JRuby so that’s going to be huge as well.

Charles Nutter gave an update in August. 45 minute mark he talks about virtual threads.

https://youtu.be/pzm6I4liJlg?si=vKVICrola4OmJIal

munificent3• 3 years ago

We recently added pattern matching to Dart [1], so I'm always keen to see how it compares to similar features in other languages. In case it's interesting, here's that Ruby example ported to Dart:

    print(switch ({'name': 'John', 'friends': [{'name': 'Jane'}, {'name': 'Rajesh'}]}) {
      {'friends': [{'name': var firstFriend}, ...]} => "matched: $firstFriend",
      _ => "not matched"
    });

Pretty similar! The main differences are that Dart doesn't have symbols, so the keys are string literals instead. Also, variable bindings in patterns are explicit (using "var") here to disambiguate them from named constant patterns.

[1] https://medium.com/dartlang/announcing-dart-3-53f065a10635

brabel7• 3 years ago

We recently added pattern matching to Dart [1]

I've been using that and I love it, in general... but can I ask you why do we need to name a variable in a pattern like this:

    switch (p) {
      Person(name: var name) => ...
    }

That's the only thing that feels a bit annoying as you have to rename the variable... In Java, this would be something like:

    Person(var name) -> ...

EDIT: I guess it's to support `Person(name: 'literal')` matches.

Dart doesn't have symbols

That's weird, as I actually use sometimes `#sym` (which has type `Symbol`)??

    print((#sym).runtimeType);

This prints `Symbol` :)

I know you know Dart in and out, but could you explain why this is not actually a symbol in the way Ruby symbols are?

adra2• 3 years ago

Virtual threads are going to be great, but they're still limited (still starved the pool when used with 'synchronized' blocks), and they aren't the structured concurrency power houses like kotlin coroutines, but its an invaluable tool that will only continue to accelerate as the ecosystem moves to adopt them.

Expect a lot of libraries to start release versions that are java 21 baseline because of this feature alone. We're in for a little bit of dependency hell for the short while. Thankfully, devs have been exposed to a mostly final loom for a year, so my hope is that at least the big projects are well on their way to quick adoptions.

Unlike the 8->11 migration which largely brought pain, the 8->21 release brings with it a ton of value that i think will encourage most shops to actually pull the trigger and finally abandon 8.

tantamounta2• 3 years ago

With the API being nearly the same, I keep just thinking that Virtual Threads are basically identical to Platform Threads except that they use far less memory (so you can have lots more of them).

Are there any other actual differences? Better Peformance?

noelwelsh• 3 years ago

The context switch time is much smaller, so yes, better performance.

pron16• 3 years ago

The relationship between throughput, latency, and concurrency in servers is expressed via Little's theorem. If your server is written in the thread-per-request style -- the only style for which the platform offers built-in language, VM, and tooling support -- then the most important factor affecting maximum throughput is the number of threads you can have (until, of course, the hardware is fully utilised). Being able to support many threads is the most effective improvement to server throughput you can offer.

See: Why User-Mode Threads Are Good for Performance https://youtu.be/07V08SB1l8c

Mawr• 3 years ago

"With the currency being the same, I keep thinking a salary of $50k/year is the same as that of $500k/year. Are there any other actual differences?"

Just as with performance improvements [1][2][3][4], the actual impact on the user experience is non-linear and often hard to predict. In the case of virtual threads, you go from needing to consciously work around a limited amount of available threads to spawning one per request and moving on.

[1] https://youtu.be/4XpnKHJAok8?t=3026

[2]: "These tests are fast enough that I can hit enter (my test-running keystroke) and have a response before I have time to think. It means that the flow of my thoughts never breaks." - https://news.ycombinator.com/item?id=7676948

[3] https://news.ycombinator.com/item?id=37277885

[4]: "Go’s execution tracer has suffered from high overhead since its inception in 2014. Historically this has forced potential users to worry about up to 20% of CPU overhead when turning it on. Due to this, it's mostly been used in test environments or tricky situations rather than gaining adoption as a continuous profiling signal in production." - https://blog.felixge.de/waiting-for-go1-21-execution-tracing...

pron16• 3 years ago

Structured concurrency in JDK 21 is not only a powerful and flexible library feature, but one that is built deep into the runtime in a way that allows observability into the relationships among threads: https://openjdk.org/jeps/453

logicchains2• 3 years ago

Do you know if clojure will be adopting these virtual threads, or still using the macro-based approach?

cogman102• 3 years ago

It's somewhat unfortunate that structured concurrency ended up being a preview feature in 21. I agree that it's a great addition but man it'd be nice if it made the LTS.

As it stands, probably won't be heavily used until Java 25.

Quekid52• 3 years ago

Congrats to you and the team on this huge milestone!

Really looking forward to taking advantage of these things (transparently and automatically!) in ZIO/Scala... which I think shows the true power of the JVM-as-platform approach you're taking!

larperdoodle• 3 years ago

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.

Brystephor3• 3 years ago

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 would it be prioritized? This is a case of "they don't know what they don't know".

I work on a team using Java 8 daily. It's fine. It's got things I wish it didn't (no null in switch statements for example) but I don't care about that so much that I'm going to go through the pain of upgrading 7-9 services in the mono repo, their dependencies, and then test them all to be on a new version of Java.

defatigable2• 3 years ago

This is a niche case, but I spent months trying to upgrade one of our services from one LTS version to the next (I forget which). We encountered a weird bug where services running on the latest JRE would mysteriously corrupt fields when deserializing thrift messages, but only after running for a little while.

After an enormously unpleasant debugging cycle, we realized that the JIT compiler was incorrectly eliminating a call to System::arrayCopy, which meant that some fields were left uninitialized. But only when JIT compiled, non-optimized code ran fine.

This left us with three possible upgrade paths:

* Upgrade thrift to a newer version and hope that JIT compilation works well on it. But this is a nightmare since A) thrift is no longer supported, and B) new versions of thrift are not backwards compatible so you have to bump a lot of dependent libraries and update code for a bunch of API changes (in a LARGE number of services in our monorepo...). With no guarantee that the new version would fix the problem.

* File a bug report and wait for a minor version fix to address the issue.

* Skip this LTS release and hope the JIT bug is fixed in the next one.

* Disable JIT compilation for the offending functions and hope the performance hit is negligible.

I ultimately left the company before the fix was made, but I think we were leaning towards the last option (hopefully filing a bug report, too...).

There's no way this is the normal reason companies don't bump JRE versions as soon as they come out, but it's happened at least once. :-)

In general there's probably some decent (if misguided) bias towards "things are working fine on the current version, why risk some unexpected issues if we upgrade?"

yCombLinks3• 3 years ago

The services I work on pump the entire business revenue from start to finish. A few nice to haves for devs aren't any where close in the risk calculation if something breaks

jfengel2• 3 years ago

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 you find one that works -- and you don't get upgrades.

The more games somebody has played with reflection, undocumented features, deprecations, etc. the more likely you are to have a conflict. And since package managers encourage you to depend on somebody else's code, you end up depending on everybody else's code.

The smaller and greener the project is the more likely it is you can just pull the latest versions and be happy about it. A project that was written when Java 8 was current, and continued to develop, is going to be a nightmare.

coldtea• 3 years ago

Other workplaces have more long term supported systems, with more complex requirements, and more SLAs and guarantees to fulfil.

kevan• 3 years ago

For an example, my team owns a dozen services and they have hundreds of direct and transient dependencies. Of those, maybe a dozen or two to need work to support the new version but that's a dozen different teams that have to put the work on their roadmap and prioritize it. When the entitlement is 'devs want to use shiny feature X with hard to quantify productivity benefit' it's difficult to prioritize. When there's an efficiency benefit then things move fast because a 10% efficiency improvement means 10% lower server costs and that's easy math.

dingi2• 3 years ago

On topic of upgrades, here are a couple of tricks I've learned throughout the years which make the upgrade process easier.

1. Use Maven 2. Use BOMs to manage related dependencies 3. No lombok

krzyk6• 3 years ago

You forgot about 8->17 which ads really nice language features, records alone are greatest feature after lambdas.

And 21 brings patterns in switch and records.

skwirl• 3 years ago

Do you have to baseline on Java 21 if you want to add support for virtual threads? Couldn't you continue using heavyweight threads on older versions of Java? My understanding is that both use the same Thread abstraction.

adra2• 3 years ago

From an API perpective, you can always use reflection to cheat past the option to create virtual threads in pre-21 (without previews) java bytecode, but you need to do more to your code than just flip the switch to support virtual threads.

A virtual thread thread pool by definition is unbound. If you're binding data to a thread (eg. Thread locals, you now have a seemingly unbound list of threads that is now effectively a memory leak). I bumped into that one a few months ago with Netty that has a per thread cache for some things (thankfully you can turn off that cache). It was creating a significantly large waste of RAM that slowed down the application alone.

The other big one is as I mentioned the synchronized limitation. If you assume naively that anything can run in a virtual thread without worries, you're opening yourself up to deadlocks or at least significantly low performance code if you're relying on libraries/code that are synchronized using java monitors.

There may be more examples of gotchas, but these two are the most notable examples I have right now.

Quekid52• 3 years ago

I believe, e.g. ZIO 2.next is doing something like this, dynamically deciding whether running something async or just doing the blocking thing depending on the availability of VThreads... but of course that's Scala, so YMMV.

Without a way to trampoline computation (or transform code appropriately) it's probably impractical to do anything like that.

(And of course, still many caveats as the sibling post points out.)

brabel7• 3 years ago

Expect a lot of libraries to start release versions that are java 21 baseline because of this feature alone.

Java has had multi-version jars since 11 I think... that allows library authors to ship code that benefits from new features in newer versions of the JDK while still supporting older ones as well. Hopefully library authors can leverage that, though I'm aware something like Virtual Threads may be very difficult to design around for older versions.

tadfisher• 3 years ago

mrjars are a terrible idea, because libraries are very rarely a single jar, and require dependencies. Often that dependency set is different depending on the runtime version because of backports of newer Java APIs. So either you don't care and make your consumers use proguard to remove the unnecessary backports, or you create a Maven package with variants for each runtime version, which 99% of your downstream will end up using anyway.

marginalia_nu2• 3 years ago

Miscellaneous new methods -- meh

Dunno, several of these are tangible QoL boosts:

Math.clamp(), List.reversed(), List.addFirst(), List.addLast(), Character.isEmoji()

bcrosby953• 3 years ago

List.reversed(), List.addFirst(), List.addLast()

These fall under sequenced collections, not "miscellaneous new methods".

marginalia_nu2• 3 years ago

I guess? I found them under the API diff linked as "miscellaneous new features".

winrid6• 3 years ago

So I can reverse a list without using "streams" now? Thank heavens

baq• 3 years ago

  > "Hello, World!".splitWithDelimiters
  >      ("\\pP\\s\*", -1)
  >  // ["Hello", ", ", "World", "!", ""]

> Meh

My brain just melted.

hinkley4• 3 years ago

I'd have a lot of uses for that. But also worry about it enabling more stringly-typed code.

mrkeen• 3 years ago

In the code example for virtual threads, I have no idea what will happen in parallel.

How do I reason about the order in which the calls change the state of the world?

Jtsummers3• 3 years ago

That's all sequential code, it would be run inside a single "virtual thread". Note that the async code on the right is also sequential, just structured through an async API.

Svenskunganka2• 3 years ago

From my perspective they're not entirely equivalent. The async variant seems to be batching getImages and saveImages, while the sync variant gets and saves each image individually, sequentially.

Someone12342• 3 years ago

If you're viewing that website on a desktop, I strongly suggest removing max-width: 90ch from the body css. Instead of 50% white space, it goes full width and makes the table substantially more readable (particularly the code samples).

munk-a• 3 years ago

Hilariously enough I was initially confused by this comment because the webpage rendered so readably for me - the base CSS is actually quite reasonable and because I have JS disabled by default the page never re-rendered into the thinner mode.

Someone12342• 3 years ago

It may be my specific setup. But on a 1440p display, 125% OS scale, I'm seeing more white left/right than actual content in the middle. It is also wrapping the code making it difficult to read.

Completely readable at 100% width though.

pacoverdi• 3 years ago

I viewed it on Firefox for Android and I immediately had to jump to reader mode for the same reason.

But I tend to use reader mode on most sites anyway because it's an easy way to get rid of banners (cookies, subscription etc.)

waynesonfire• 3 years ago

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 gives a shit about quality? Mark it zero!

specialist2• 3 years ago

Randomly looking at bugs fixed the last 10 weeks, it seems like a healthy mix of old and new bugs.

https://bugs.openjdk.org/browse/JDK-8316305?filter=-7&jql=pr...

Being allergic to JIRA, my JIRA-fu is weak, so there's probably an easier/faster way to report bugs fixed in v21.

Any way.

Am I the only one around here who gives a shit about quality?

Ages ago, I was a QA/Test manager. So I appreciate your sentiment. But it seems to me that Oracle's being a FANTASTIC shepherd of Java. Definitely a huge upgrade, at the very least.

doodpants• 3 years ago

You might be the only person in the world who writes bug-free code on the first try.

rr8082• 3 years ago

Java has been around for nearly 30 years, I'd hope the core libraries had very few bugs by now.

pron16• 3 years ago

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.

billfruit• 3 years ago

Does it add stdint style names for integer types, unsigned integer types etc?

layer8• 3 years ago

The size of the integer types are already fixed by the JVM specification (int is always 32 bits, etc.), and there are no unsigned integer types in Java except for char (a 16-bit unsigned integer type). Furthermore, Java does not support alias names for types. Hence it’s unclear what your question is aiming at.

szatkus• 3 years ago

AFAIK Java 8 added a few methods that helps you handle integers as if they were unsigned, like `toUnsignedString`. I think it's enough for any exotic cases.

PaulHoule• 3 years ago

(1) It's a bit of a bad smell (which he points out) that records aren't being used much at all in the Java stdlib, I wrote something that built out stubs for the 17 and 18 stdlibs and that stood out like a sore thumb. I do like using records though.

(2) I've looked at other ways to extend the collections API and related things, see

https://github.com/paulhoule/pidove

and I think the sequenced collections could have been done better.

(3) Virtual Threads are kinda cool but overrated. Real Threads in Java are already one of the wonders of the web and perform really well for most applications. The cases where Virtual Threads are really a win will be unusual but probably important for somebody. It's a good thing it sticks to the threads API as well as it did because I know in the next five years I'm going to find some case where somebody used Virtual Threads because they thought it was cool and I'll have to switch to Real Threads but won't have a hard time doing so.

papercrane2• 3 years ago

I suspect if we had records from the start they'd be all over the stdlib, but because of backwards compatibility they'll likely only be considered for new APIs.

twic2• 3 years ago

I think the biggest impact of virtual threads is that the ecosystem will abandon asynchronous APIs. No more futures, callbacks, servers where you have to make sure not to block the thread, reactive frameworks, etc. Just nice simple imperative blocking code. Nima is the first example i've seen:

https://helidon.io/nima

We've had two production bugs in the last two weeks caused by handlers blocking the server thread in apps using an async web framework, which would simply not have happened with a synchronous server.

jayd16• 3 years ago

You'll still have the structured concurrency calls but that's much better than pure callback hell.

winrid6• 3 years ago

They won't abandon async callback based code.

VT have too much memory overhead to be equivalent.

yankput2• 3 years ago

Virtual threads are strictly better than normal threads, no? I am thinking of any reason to still use traditional threads. Is there any downside?

papercrane2• 3 years ago

Currently virtual threads aren't a good match if you have a CPU heavy workload. The scheduler isn't fair and if your code doesn't enter into any blocking code it won't be unmounted from the carrier thread.

zmmmmm2• 3 years ago

I think virtual threads are huge.

The problem with regular threads is (a) multi-kb memory stack per thread and (b) consuming a file handle.

Either of those severely limits the scalability of the most "natural" parallelism constructs in Java (perhaps generally). Whole classes of application can now just be built "naturally" where previously there were whole libraries to support it (actors, rxJava, etc etc).

It make take a while for people to change their habits, but this could be quite pervasive in how it changes programming in general in all JVM languages.

riku_iki13• 3 years ago

Either of those severely limits the scalability

you can avoid both issues by using 20yo executorservice.

fulafel2• 3 years ago

You could easily have a million threads if you use multi-kb stacks. Million times multi-kb means multi-gb, that's still 3-4 orders of magnitude less than big memory servers/VMs. (and 1 order of magnitude less than a normal laptop)

What do you mean by using a file handle, is this a Windows platform thing? On *ix, threads don't use up file descriptors (but you can still have a million fd's at least on linux for other stuff if you want).

Vicinity9635• 3 years ago

The examples having to word wrap in a tiny text box look even more absurd and unreadable when the page is only using 1/3rd of the screen.

What is with this awful formatting? https://i.imgur.com/nQmt7Qo.png

BrianKamrany• 3 years ago

It is easier to read something that is page-sized, as opposed to taking up the full screen. Although it does look weird.

hinkley4• 3 years ago

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

Google is not helping.

discodachshund• 3 years ago

The Typelevel folks on Discord are of the opinion it's not of much interest to them

hinkley4• 3 years ago

I wonder if that's "not interesting" or "we already fixed this another way"

dionian2• 3 years ago

It's great, but irrelevant since Scala is already so far ahead. I will start to care if i am ever forced to do java again. I love how much better Java is getting! Most of these things we have had in scala for a long time already, and much better versions.

rr8082• 3 years ago

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.

vips7L3• 3 years ago

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

logicchains2• 3 years ago

Does anyone know if Java virtual threads will also have channels and a select concept, like in Go?

aardvark179• 3 years ago

I think at some point yes. We certainly discussed it but it’s one of those things that takes time to really get right and performant.

kaba05• 3 years ago

Java already has many more concurrent and parallel data structures, so while it likely won’t have a keyword, it can definitely do it already.

shaunxcode• 3 years ago

Just spit balling but you should be able to use clojure core async channels and the blocking put/take/alts functions. Would probably take a small amount of work to expose those things to Java in an idiomatic way but should be doable. Please take all of that with a giant grain of salt though!

anonymousDan• 3 years ago

Can anyone explain this comment: "In the past, a thread pool didn't just throttle the incoming requests but also the concurrent resources that your app consumed. If you now accept many more incoming requests, you may need other ways to manage resource consumption."

yCombLinks3• 3 years ago

Yeah, if your server maxed out at 256 system threads you didn't have to worry about the fact that 1024 simultaneous calls would crash your DB. But now you're not limited by system threads

YeBanKo2• 3 years ago

You can still use connection pool + platform threads. Or executor with virtual threads and semaphores or blocking queues. It’s mostly a concern for someone who implements a connection pool, for most devs it’s gonna be the same config option of max connection, that you need to pay attention to.

Any modern web app already has multiple instances of the app querying a db, so you have to keep a tally of total connection number either way.

hoistbypetard• 3 years ago

It sounds like it has some neat new features. But I'll never know because I'm never again going to use another Oracle thing. There's not a thing they could make that's good enough for me to agree to one of their EULAs and install it. Their behavior in that area is just staggeringly bad.

matt_heimer• 3 years ago

Then use Java without agreeing to an Oracle EULA. You can get a GPLv2 open source build from https://jdk.java.net/21/

If you don't trust the Oracle based open source builds then just wait a bit for Microsoft, Redhat, and others to release their version 21 OpenJDK builds that will be found under https://adoptium.net/marketplace/

kaba05• 3 years ago

Not this bullshit again.

aggregat• 3 years ago

We have 2.1 million LOC in Java and we're moving to Java 21 (from 17) in two weeks when we branch for release.

We have a hundreds of third party dependencies across the code base, a lot of the big ones (Hibernate, Spring, a lot of Apache). We write a big web application and maintain a big legacy desktop application in Swing.

We run a dedicated nightly CI job that is on the latest Java release to get early warning for any incompatibilities. After the painful migration from 8 to 9 so many years ago it has been smooth sailing.

In all those version upgrades over all those years and dozens of on premise installations with big customers we have never had a regression or a problem that was caused by the runtime itself.

sylware• 3 years ago

I am looking for assembly implemented JVMs (x86_64/risc-v/etc), that to remove SDK pressure and give stable auditability of machine code.

Do those exist?

ivanjermakov• 3 years ago

I love pattern matching, but without a proper support for variant types it won't be as useful as it could.

I'm aware of `permits` clause, but it's not good enough.

bullen• 3 years ago

So it's just Thread.startVirtualThread(runnable); that's it?

Going to be interesting!

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

Related Stories