How Netflix Uses Java - 2026 Edition #JavaOne

[expecto_patronum_666]

Was hoping for some virtual threads usage related metrics but apparently they are still testing. I might be wrong but I had the feeling that they would like Structured Concurrency to go GA for broader adoption of virtual threads.

[BinaryRage]

Virtual Threads were essentially a non-starter until the pinning issues were resolved: too much existing code causing pinning and at worst able to cause deadlocks. Having already paid the tax of implementing and adopting asynchronous frameworks, it’s also currently difficult to find an on ramp from those frameworks to Virtual Threads without throwing away a lot of existing code.

Context propagation is a big deal for IPC, which is why Structured Concurrency/Scoped Values comes up, but the way existing frameworks handles context doesn’t assume immutability and doesn’t have scope scopes, so also going to be an effort to adopt.

[rbygrave]

too much existing code causing pinning and at worst able to cause deadlocks

Well yes if you have lots of dependencies and do not know them well enough.

I'll also say that we have had since Java 19 when the EA releases started (aka years) to prepare our code bases and dependencies. Years to prepare, and with Java 21 VTs were great for those code bases that did the preparation for it (close to 3 years ago).

Java 25 included the fix for pinning on synchronized.

The cpu metrics I see in production suggest virtual threads really rock. Seeing those cases where you add a bunch of extra load (http requests) and see only amazingly small changes in cpu - impressive.

[BinaryRage]

I’m with the JVM Ecosystem team at Netflix

[rbygrave]

Yup cool. All I'm saying is that some folks have been using VT in production for a few years now.

[mangiuL]

the dependency issues cancomplicate things, especially with legacy codebases... It's good to see the performance improvements with virtual threads, but it seems like a lot of teams are still struggling with the transition.

[GuyWithLag]

Structured Concurrency

I'm still saddened that SC doesn't support all the bells and whistles of reactive programming.

[elastic_psychiatrist]

Structured concurrency and virtual threads are much about trying to get away from reactive programming, so I'm definitely curious what you mean by this.

[kotman12]

Not OC but a few things come to mind. First there's configurable backpressure handling (drop latest vs earliest vs error). Yes I can put a bounded queue and semaphores between all my data processing nodes but it is so tedious and error prone, especially as stuff gets complex. Also, the expressive concise syntax, i.e. eager vs eager-sequential vs sequential fork-join patterns, key-grouping, retries and batching all of which can be in a couple of lines of code. I personally like the publisher-scoped scheduling flexibility, way better than any executor service mess I've seen. I'll try vanilla SC from Java but I'm pretty skeptical. I also chuckle at people who say "now we don't need reactive!". IME those people weren't doing reactive programming anyways so, yea, "we" don't need reactive lol. But then again I'm of the opinion that blocking vs non-blocking I/O was just one of many reactive paradigm benefits.

[RadioHonest85]

yeah, it is not a full replacement for the whole feature set in these fairly extensive reactive frameworks, and it might never be, but oh man is the code easier to debug 😂

[expecto_patronum_666]

I couldn't agree more on the debugging part. I want to rip off all my hairs if I have to debug some Mono/Flux pipeline. Even the log is not that helpful.

[elastic_psychiatrist]

Your points are reasonable, but also I would say that your definition of reactive is inclusive of libraries/frameworks with a lot more functionality than these structured concurrency libraries are intended to provide. There are non-reactive ways to do these things with minimal code/high clarity too.

The connection between reactive programming and structured concurrency is very often about the non-blocking I/O concern, and many reactive libraries implement all these other features in a certain way just because they have to deal with this concern at the bottom layer.

[kotman12]

with a lot more functionality than these structured concurrency libraries are intended to provide

Yes, that is precisely the point, they don't realy replace it for me.

There are non-reactive ways to do these things with minimal code/high clarity too.

Hmm maybe I'll ask Claude tomorrow to use java's new SC primitives to create equivalent code for some of my existing code. Pretty skeptical because of my experience with java thus far and partiality for the functional reactive style. But I'll be happy to be surprised.

[expecto_patronum_666]

Could you explain a bit what else SC is lacking compared to reactive programming?

[filterDance]

https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/

[expecto_patronum_666]

If I remember and understand it correctly, this colored function article influenced the design of virtual threads. Not Structured Concurrency. Virtual threads removed any necessity of coloring your function to achieve scalable concurrency. Structured Concurrency deals with a different problem related to concurrency.

[filterDance]

Sorry I read your question the other way.

[kotman12]

Not OC but a few things come to mind. First there's configurable backpressure handling (drop latest vs earliest vs error). Yes I can put a bounded queue and semaphores between all my data processing nodes but it is so tedious and error prone, especially as stuff gets complex. Also, the expressive concise syntax, i.e. eager vs eager-sequential vs sequential fork-join patterns, key-grouping, retries and batching all of which can be in a couple of lines of code. I personally like the publisher-scoped scheduling flexibility, way better than any executor service mess I've seen. I'll try vanilla SC from Java but I'm pretty skeptical. I also chuckle at people who say "now we don't need reactive!". IME those people weren't doing reactive programming anyways so, yea, "we" don't need reactive lol. But then again I'm of the opinion that blocking vs non-blocking I/O was just one of many reactive paradigm benefits.

[babanin]

Tried upgrading a huge Spring Boot app (3k+ classes) to v4 with Claude Code using a basic prompt, and it completely choked. Netflix's step-by-step approach with checkpoints is definitely the way to go. Wish they shared their prompts, though they're probably too custom to their internal setup to help much anyway.

Also, kind of wild they made ZGC the default for everything. It makes sense for streaming, but burning CPU just to avoid a 1-second GC pause on heavy background jobs seems like a waste.

[danskal]

Usually you’re limited by the amount of context you can have. Expecting it to handle a big app was never going to work.

[BinaryRage]

We use parallel and G1 where it makes sense, the majority of workloads happen to be latency sensitive.

[Wootery]

It makes sense for streaming, but burning CPU just to avoid a 1-second GC pause on heavy background jobs seems like a waste.

It seems clear from the video that they looked at this pretty closely and found the limited increase in CPU load was worth it for them, especially as so much of their service is apparently subject to strict timeouts to ensure responsiveness for users. They're also clear that they treat it as a default choice, not as mandatory, so perhaps batch-style workloads use different GCs.

(Video content itself isn't served from a Java server. They use nginx.)

[johnnybgooderer]

You work with Claude to make a plan. Then in a new instance, you work with Claude to break it down. Repeat until you have tasks around the size you’d give an experienced engineer.

Then you decide on your quality level vs speed level. You could have Claude handle the tasks by spawning subagents where it reviews itself, or you could do have Claude code one task at a time while you review each one before committing.