Even without that support, if you return interfaces instead of the concrete type each return can be a different implementation. There is no need to have one giant class. All of those methods in his example should return IJdkRequest, not JdkRequest.

That doesn't help at all because all the methods will still have to be declared in IJdkRequest and implemented by every concrete subtype returned by the methods.

IJdkRequest would inherit other interfaces, so the other methods would be declared there. The default implementation could be handled by a base class.

And now that I typed it out, I see how it also doesn't really help. I see your point. I'm not sure what's worse, one giant class, or the handful of interfaces and abstractions just to make it work in multiple classes.

Came to say the same thing. In Rust, you can also have fluent interfaces that return different types as you build, which means that you end up being more typesafe throughout the construction process.

Even in Java: if you want your fluent builder to be extensible, that's easy enough to achieve with a base class that returns a generic self type in the fluent methods. If lack of extensibility is the strongest criticism of fluency, then fluency must be great.

I use extension methods extensively, and it keeps the code closer to where it's used and the classes they operate on clean. It's a huge win for maintainability.