That's reactive programming in Java, where you return a callback to be run when an operation completes.

The giveaway is the Mono<T> return type.

My eyeballs bleed, and I'm pretty comfortable with Java for many years.

I see the most of it stems from reactive-style programming (reactor.core.publisher.Mono).

Maybe they just tried to fit into one screen? Anyway I'd ask to simplify it, if I was a their team lead.

100% test coverage (fingers behind back).

Is this what people have to do when they don't have the C# async/await autogenerated state machine?

Yup. Although to be honest it probably doesn't need to be reactive.

Yes and no. This is a common pattern, but implemented very lazily. Most of this can (and probably should) be refactored out to separate classes/functions.

But no, I don't think this would faze most Java devs. It's ugly and bad practice, but more or less acceptable depending on personal taste. It works, at least.

Point of interest: LLMs tend to go too far in the opposite direction with code like this. They will break everything apart into functions or classes, even trivial one-line lambdas. I find that even more obnoxious than the monstrosity you linked.

I can tell you as a person working in a spring boot webflux shop that is pretty bad code. You really don’t want to nest that much. Using atomic references outside the reactive flow is a huge red flag that they don’t know how to program in webflux properly. Not that webflux is easy to use at all and the dx is garbage.

> Not that webflux is easy to use at all and the dx is garbage

My experience with pretty much any Java framework ... It's sad because I do think (especially since Java 8) that Java is a great language for many things. But the community as this insane tendency to create incredibly convoluted pattern-on-top-of-pattern tooling.

Yes. I think micronaut is kind of the sweet spot right now.

With virtual threads it's difficult to see WebFlux being used in new projects.

I agree. Unless you actually need back-pressure, which almost every use case I've seen does not, it's just obfuscating simple API calls.

I've seen similar things, in Java as well as some other languages. It's obviously not the preferred way of doing it.

Unreadable+undebuggable has been the preferred way of doing it for as long as I have seen software

Seems perfectly readable to me, and I haven't used Java professionally in over a decade. What specifically do you find problematic?

The ~12 levels of indentation and 5 layers of nesting are doing my head in personally but maybe my brainspace is too small.

I think this perspective explain the issue well: you pretty much cannot unit test this (unless you consider the whole function a unit). It becomes very unclear what each lambda expression is about, the deeper you get.

I don't really know Java, but .flatMap(...) seems to be equivalent to C# .SelectMany(...) which famously can be interpreted as a monadic bind operator.

The C# query syntax

  from x in xs
  from y in GetYs(x)
  from z in GetZs(y) ...

is equivalent to

  xs.SelectMany(x => GetYs(x).SelectMany(y => GetZs(y).SelectMany(z => ...)))

which is similar to monadic do-notation in Haskell.

So since there is monadic Scala code elsewhere in the project, I wonder if this is a result of someone thinking in Scala and translating it into Java in their head.

It is if you’re doing government style work and you want have a job for life creating code that nobody else can read.

Or if you’re in the business of selling extremely wide aspect ratio monitors.

It is nested sure but the entire thing fits on 1080p monitor

Well... depending on your default level of zoom.

After staring at code for 12 hours a day for a few decades my zoom is 125% by default.

Careful, at this rate your zoom level will be an unreadable 900% after only a few centuries...

So long as you abandon the concept of windows and run your text editor in full screen mode. Good luck with side-by-side diffs.

Better make those monitors curved

The atomics are goofy, but reactor can often lead to messy code structure when you actually need sequential blocking behavior.

It's very common to see from devs that don't really grasp reactive programming. You often see similar things in Angular projects because of RxJS.

> .onErrorResume

I dislike Java but if it can get me back to the On Error Resume Next days I might reconsider.

If you are a non-Java developer, it does look daunting. But in my opinion it’s much much better use of the Java streams api and reactor library that I have seen compared to most shitty corp firms.

I saw an internal “sso” auth app that iterated a byte array and concatenated the values into a string instead of base64 encoding it when I worked at HP/HPE/DXC

Looks like callback hell, but in Java. Async/await would solve it, but it's Java.

Fuck no, it's not. But I've seen it because it gets promoted by some smartass tech lead chasing so called webscale performance. But they never do comparative benchmarks against regular blocking code for fear that it would demonstrate the true nature of their head trip. Then they leave to go shit elsewhere and leave other people to deal with the consequences of their hubris.