News Letter Article - Quarkus with Java Virtual Threads

[gesker]

There was an article in the recent Quarkus News Letter with the title Quarkus with Java Virtual Threads by piotr.minkowski @piomin

I was just wondering if there were some dev images published that could be used for taking @RunOnVirtualThread for a spin on local/dev K8s?

quarkus.native.builder-image
quarkus.jib.base-jvm-image
quarkus.jib.base-native-image

Instead of rolling my own vs graalvm was kind of hoping there were dev images already in use by the community for experimentation. Not looking for anything official just looking to play a bit.

Thanks,
Dennis

[quarkus-bot[bot]]

/cc @geoand

[geoand]

Thanks for your interest!

I am not sure I understand what exactly these dev images would provide. Can you elaborate a bit?

[gesker]

Hi @geoand

Currently most of our micro-services that use Quarkus have:

quarkus.native.builder-image=quay.io/quarkus/ubi-quarkus-native-image:22.2.0-java17
quarkus.jib.base-native-image=quay.io/quarkus/quarkus-micro-image:2.0
quarkus.jib.base-jvm-image=registry.access.redhat.com/ubi8/openjdk-17-runtime:1.14

There were a few pain points jumping from JDK 11 to JDK 17. Nothing like when we jumped from JDK 8 to JDK 11 when we were mostly monolithic but still it chewed days.

While the next LTS of the JDK isn't until 2023 we'd like to:

1. Setup up a pipeline against interim JDK release so we are not behind the curve for the next LTS. Big jumps from LTS to LTS, as above, haven't been fun.
2. Have some kind of alignment in these pipelines so source/target/openjdk/graalvm are in alignment as much as possible likely using 23.0.0-dev-20221012_2107 for the time being.
3. Avoid written in JDK Y but running on JDK X.
4. Carve off a few of our services and really try out features like @RunOnVirtualThread, and Virtual Threads / Scopes generally to see truly see where it is beneficial and determine an estimate of how long to refactor. Virtual Threads seem significant enough in JDK 19 that it deserves our attention and the news letter article by @piomin did get our attention.
5. It would be nice if we could just script/update application.properties files across from our base pipeline to this "anticipatory" pipeline:

quarkus.native.builder-image
quarkus.jib.base-native-image
quarkus.jib.base-jvm-image

And, it would be ideal if we were using images similar to what others are using that also wish to stay current with new features being release in the JDK and are using Quarkus. Internally, we are kind of looking at rolling our own images as a containerized version of "well it runs on my machine/image." Not a huge deal to roll these ourselves but still our thinking is better to be aligned in some fashion.

The JDK moves fast these days. While not everything is a "must have now item" if there is a pickup for us we'd like to include it sooner rather than later and more importantly get it into our road map well in advance with some rough estimates as to the effort extended that will be required to utilize a language feature. Generally, little JDK hops may be better for us than hopping from LTS to LTS.

Dennis

[geoand]

Gotcha, thanks!

@cescoffier WDYT about ^?

[cescoffier]

Unfortunately, the images you want are not yet available:

• quarkus.native.builder-image=quay.io/quarkus/ubi-quarkus-native-image:22.2.0-java17 - I don't believe we have Mandrel with java 19 support yet
• quarkus.jib.base-native-image=quay.io/quarkus/quarkus-micro-image:2.0 - unchanged, this one would work (but it does not provide java)
• quarkus.jib.base-jvm-image=registry.access.redhat.com/ubi8/openjdk-17-runtime:1.14 - it won't be produced. It is only for Java LTS

At least for the last one, you would need to build your own image.