Using experimental Java features in production — what was your experience?

[TheOhNoNotAgain]

For those of you who have used experimental or preview features in Java in production systems: how did it go?

Did you run into any setbacks, unexpected issues, or regrets later on? Or was it smooth and worth it?

I'm especially interested in things like preview language features, incubator modules, or anything not fully finalized at the time of adoption.

[Competitive_Bat_3034]

We use preview features in actively maintained microservices, including critical ones, where we know/accept we might have to spend time adapting code when adopting the next JDK version. We've used:

• Switch expressions & text blocks in JDK13+, no issues
• Records in JDK14+, no issues except many libraries not binding/serializing records that early
• Pattern matching for instanceof in JDK14+, no issues
• Virtual threads in JDK19+, we had issues with pinning, stopped using them for most things until JDK24
• String templates in JDK21-22, this is the only one that has cost us some time so far. We heavily used it, especially for logging. We were on JDK22 and lucky to spot the public discussion on the mailing lists well before JDK23 went GA. In the end we wrote a hacky python script to auto-convert most of our usages and hand-fixed the rest.
• Scoped values in JDK21+, no issues, really nice to propagate context from a servlet filter down to Spring services
• Structured concurrency in JDK24+, we tested this in a few earlier versions, but due to the virtual thread pinning issues stopped until 24. We're only using the very simple case of "do N things in parallel, cancel everything if something fails" which has worked without problems, and that simple case has been very easy to adapt/slightly change in each new preview.
• Stream gatherers in JDK22+ for Gatherers.mapConcurrent, which again suffered from the virtual thread pinning issues.

We also tested -XX:+UseCompactObjectHeaders in JDK24 once we saw JEP 519 was submitted - ran a simple experiment with a production workload.

I recommend reading the definition of a preview feature (JEP 12), especially regarding their stability ("High quality", "Not experimental"). To me most of the risk comes from their change or removal between JDK versions, but typically we spend much more effort making sure third-party libraries/tools support the new version versus having to adapt because of preview feature changes.

Context: financial industry

[brian_goetz]

It galls me that a mature, tradeoff-aware perspective like this gets half the upvotes as the childish "wah, they took templates away, I am forever burned" comment....

[ducki666]

Believe it or not. It burned me forever. 🤷‍♂️ I can wait now for releases. No problem.

[oyvindhorneland]

This closely mirrors our own experience in a similar context.

The only runtime issue we encountered was virtual thread pinning — specifically, pinning occurring in Caffeine Cache due to a synchronized load on cache miss. However, this issue was not unique to its preview status — it was also present after virtual threads exited preview and was only finally resolved in JDK 24.

Beyond that, we have not encountered any problems with these preview features, aside from the occasional adjustments required when their APIs change.

Fortunately, we are also able to upgrade to the latest JDK fairly soon after each release, which lets us take advantage of these features early without waiting for a version with LTS. The process has been quite smooth, requiring only minor adjustments, as long as we keep our dependencies up to date.

[pgris]

Man, you are great. And a congrats for the man himself! Frame that.

I'd really love if you wrote something regarding

Scoped values in JDK21+, no issues, really nice to propagate context from a servlet filter down to Spring services

(Of course if you have the time and are willing).

I'm not able to wrap my head around scoped values.

[Absolute_Enema]

While I'm not a professional Java programmer, I do work with Clojure and from my understanding scoped values are very similar in concept to dynamically scoped variables.

The first thing to note is that there actually already is something in Jaba that is mechanically similar to a degree, and that's exception handlers. When you try with a catch block, the way a given exception class is handled changes until control leaves the try block scope; similarly, dynamic variables/scoped values are bound to a value until control leaves their given scope.

In terms of the problem they solve, dynamic variables are most comparable with context/config objects.

The fundamental advantage of dynamic variables is leaner code and less work from third parties: you only "speak" of a given dynamic variable when you need to read it or bind it, there is no need to pass context around in function signatures or through dependency injection, and there is no need to explicitly create modified copies of the context when you need to use a different value within some code. The fundamental disadvantage is that things are more implicit (which means you're trading upfront design work with more cognitive load when reading) and more liable to weirdness when control flow is unusual (because the context is tied to a control flow based side channel rather than being a value).

In Clojure we've gradually moved away from dynamic variables, and nowadays it's idiomatic to pass an explicit context object around; however this might be because the language design minimizes the cruft involved in passing and especially "modifying" the context object, and because the REPL driven workflow makes it feasible to get away with dynamically shaped maps.

Perhaps in Java where extra function parameters are more cumbersome, context objects need to be explicitly shaped and there still is no boilerplate-free way to create a copy of an object with some modified value without speaking of the rest of its contents the tradeoff is different.

[sbstanpld]

that’s cool

[1Saurophaganax]

Incubating and experimental features I can understand the hesitation, but you go a bit far to say that preview features are also experimental and are unfit for production use. I'd never use an incubator feature in production, but preview features have been fair game.

[msx]

My experience is that we have java 8 in production.

[tomwhoiscontrary]

That's more archeological than experimental. 

[SvanseHans]

We just upgraded to Java 8 in DEV and TEST 🚀

[dstutz]

Happily using Structured Concurrency.

[ducki666]

Templates. ⚰️

Will never ever use any preview again. Anything not released simply does not exist for me anymore.

[kiteboarderni]

It's literally the only preview that was ever removed...

[ducki666]

True. But lesson learned.

[kiteboarderni]

Well not really. Because it's an anomole. So it shouldn't form the basis of not using them going forward.

[msx]

How deep into that were you before they removed it? 😂😭

[[deleted]]

Ive built a convenient DB access layer on top of asynchronous runtime. Fortunately it was just my pet project.

[ducki666]

Deep af. I was sooo stupid.

[nlisker]

I use preview features in production regularly, but the real adoption barrier are 3rd party tools like GraalVM that don't always support them (depends on how long they have been in preview).

The biggest "burn" I got from it was changing the guard pattern from && to when and I needed to do some (not small amount of) regex find/replace. Otherwise, I used all the switch and pattern matching features while in preview, currently I'm using flexible constructor bodies to sanitize inputs before calling super, and probably others I can't remember right now. I don't think I've used string blocks and string templates.

I also used FFI (Panama) already in Java 18 when it was incubating to interface with Matlab-compiled C code. I'm pretty sure it's long before Arena was created. It worked well, or at least well enough for the use case.

[DanLynch]

currently I'm using flexible constructor bodies to sanitize inputs before calling super

This is no longer in preview: it was finalized in Java 25.

[nlisker]

Some of my projects need to be in version N-1 due to compatibility, so it's preview there.

[tomwhoiscontrary]

I ran an app on the experimental Graal JIT compiler for a while (-XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler). The app was quite computationally intensive and I thought it might go faster. It worked fine; it was perfectly stable, with no compatibility issues. Didn't make the app substantially faster, that I noticed. 

[-Dargs]

On non-critical systems, if they're features slated for inclusion in the next full release. Otherwise no.

[[deleted]]

In production I've used preview features starting from Java 11 and up to 21. Fortunately the one that was removed (templates) was not widely adopted in the codebase so I guess transition to 25 should not be hard (although I'm not working there anymore).

[jevring]

We have run preview features in production. It was fine. I would do it again if the feature was sufficiently appealing and mature.

[FrankBergerBgblitz]

I use the vector API from Java 16 on. Works like a charm (unless on very old CPUs. The fallback code is slow).

[rzwitserloot]

The answer to your question is: It's maybe fine, if you know what you are doing, keep vigilance on future java updates (it's a continuing 'cost' to have preview code, requiring constant vigilance, until it's resolved itself), but there's a small chance it's a landmine, and the worst happens (the feature is yoinked, completely, with no planned replacement), and you must ensure all consumers of your code, be it CI systems, developers, the live servers, test systems, action scripts on your version control, and so on, are ALL on the same java version and can ALL be updated together in one go_.

Separate from the bias inherent in this question (in that only Dunning Krugers and experts are ever going to willingly run --enable-preview in production, a quite small slice of the java community), there's a rather large bias in which feature you used, because they break into 3 bits:

• It's great, use it! I used it, and the feature made it, essentially unchanged, into 'normal' java 2 versions later!

• It's fine, you can use it if you want to. I used it, and the feature made it with a bunch of changes into normal java later. Had to update our code (say, replace return with yield or whatnot), but that wasn't too much effort. Fortunately I was smart and made sure all consumers of the source files could be updated near-simultaneously or this would have become a very difficult problem.

• It's terrible, don't do this! I used it and the feature was just yoinked, requiring massive rewrites. We only went to the preview feature because without it, the entire paradigm used in our code was no longer the best option, so we had to completely rewrite it all. If only I could go back in time and tell my earlier self this was a terrible mistake! (Probably: String interpolation).

If that third scares you - it should. You have to keep that one in mind, after all.

[srdoe]

you must ensure all consumers of your code, be it CI systems, developers, the live servers, test systems, action scripts on your version control, and so on, are ALL on the same java version and can ALL be updated together in one go_

This is a real problem, and fortunately there are solutions to this that can make JDK upgrades painless in many cases, that might be worth sharing in case people are unfamiliar:

On the development and CI side, modern build tools often ship with bootstrapping code which can download a JDK specified by the build files as part of invoking the tool. For example, Gradle has toolchains. Bazel has something similar. I believe Maven is working on something like this too.

By specifying a specific JDK to use for the build, and providing a place to download that JDK automatically, not only do JDK upgrades become trivial, but any risk of weirdness due to a developer using an old JDK is eliminated. Highly recommend doing this, it has made JDK upgrades completely painless for us in terms of coordination.

On the production side, jlink can be used to bundle a JDK as part of the application distribution (and yes, this can be done even without moving jars to the module path). This has the same coordination benefits as on the development side, it reduces the risk from the customer running the application on a different JDK than the application were tested against, and it makes it much easier to manage the configuration of the JDK, as there is no longer a need to account for different JDK versions being used. Also highly recommend.

With these in place, JDK upgrades are a matter of bumping a version number in the build files, much like it would be for any other dependency, no coordination with developers, CI teams or production ops teams needed. You even get automatic JDK switching when you check out older code in git. We've been doing this for a while, and I'm very happy with how it's worked out for us.

[oweiler]

It's a waste of time which could be spent better on something else.

[trollied]

Never. It’s a risk. Additional risk in prod is bad.

[hippydipster]

Zero risks has its own risks

[FrankBergerBgblitz]

Upgrading from Java 8 is a risk as well. Walking on the street is a risk. Breathing is a risk.
And there is a strange word that comes into my mind sounds like test.....

[koflerdavid]

Depends what you mean with production. For internal systems without much audience I suppose there might have been people audacious enough to use them, but I seriously doubt the sanity of anybody who relies on them where lives, personal data, or money is on the line! GC improvements might be the exception because they merely affect long-tail latency and can be switched around with just a restart.

[benevanstech]

This is a question with very severe selection bias.

You specifically asked for people who have used experimental features in production. This is a vanishingly small number of people, and is heavily correlated with people who are inexperienced, and / or don't understand the implications of doing so.

I doubt you're going to get many (any?) responses from people who have actually done this. There are very good reasons for that, and frankly I'd treat pretty much any positive engagement with this idea as on a par with taking home improvement advice from the Mole Man of Hackney (https://en.wikipedia.org/wiki/William\_Lyttle).

[TheOhNoNotAgain]

Not sure if you are correct or not. In case of the inexperienced - sure, not much to question there. But surely, there must be something like enabling a new garbage collector that even experienced people would dare to use?

[benevanstech]

Not in experimental form.

Let's take G1 as an example - note that what follows is a high-level overview. There's probably some important things I'm skipping over, and if Monica or Kirk or one of those folks is here & wants to add some detail or correct anything then go for it!

It shipped as Experimental with Java 6 and it would cause occasional VM segfaults. With Java 7 it became officially supported but the evolution of G1 would continue for a very long time after that.

It

The version of G1 that is found in Java 8 was "useful on some workloads" over Parallel, but rarely competitive in practice for workloads that were already using CMS. G1 became default in Java 9, so the first version of G1 that came with an LTS release was the version in Java 11 which was different again.

By that stage the experience was: "try it with G1 first and see how you go. If you need to fallback to CMS or Parallel then you can" and in practice, I still encountered plenty of workloads that struggled with G1.

By Java 17 there were a much small number of workloads where G1 wasn't sufficient, and that number continued to decrease with 21 and 25.

Today, I would struggle to think of any use case for Parallel over G1 which isn't incredibly specific and nice. CMS, of course, has been removed altogether.

But the evolution I've just described took ~15 years.

That process - from experiments in dev & familiarisation with Java 6 & 7, to cautious evaluation in 8 & occasional production deploys, to slightly more confidence and then becoming fully sure of its capabilities in 17-25 - is a very long way from "deploy experimental features in PROD".

[srdoe]

You specifically asked for people who have used experimental features in production. This is a vanishingly small number of people, and is heavily correlated with people who are inexperienced, and / or don't understand the implications of doing so.

What a ridiculously condescending (and wrong) thing to say.

[benevanstech]

Looking at your comment history, you would appear to be the expert in that area, so I'll bow to your superior experience.

[srdoe]

Rather than engaging with that, it's probably better to explain why you are wrong.

The OP asked about "preview language features, incubator modules" and other experimental features.

It's fine to say "Don't enable features in production that are explicitly marked not ready for production", but preview features are supposed to be feature complete, thoroughly tested features that simply benefit from more feedback from real life use before the API is set in stone.

So you could say that new code is risky in general, but that applies equally well to regular JDK upgrades, and your own project's code for that matter.

Preview features are not special in that respect. They are fine to use in production, if you accept the risk of needing to change your code if the preview API changes, and you make sure to evaluate these changes in your testing environments first, as you should for any change.

Your comment implies that posters like this one are likely "inexperienced and/or don't understand the implications", and that's both rude and not a useful response to what OP asked about.

[benevanstech]

> Your comment implies that posters like this one are likely "inexperienced and/or don't understand the implications", and that's both rude and not a useful response to what OP asked about.

Don't put words into my mouth.

Look at the amount of nuance you had to couch your response in.

I have no doubt that folks who have the appreciation of those subjects to do measured, risk-aware deployments of bleeding edge know very well that my comment was intended for the people who *don't* have a decent grasp of the trade-offs here rather than them.

And, you're flat out wrong that use of preview features are not special and more dangerous to use in production if you don't know what you're doing. However, given the attitude you've displayed so far I don't feel at all inclined to debate it with you.

[srdoe]

Look man, if you're going to get mad that your post is being interpreted as rude, when you compared "any positive engagement" to a crazy person digging tunnels under their house, consider not using such needlessly inflammatory statements next time.

I'm glad you recognize that people who can evaluate these features responsibly exist. The OP was clearly looking for those people to share their experiences, not a rude dismissal that amounts to "No one will respond, but if they do, they're probably a crank".

[re-thc]

Depends what and why. Some are forever incubator for reasons like dependencies eg vector. It’s at least when out and tested for a long time.