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.

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

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.

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

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.

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.

Really puts that whole "our wonderful journey" "our incredible team" post into context, haha.

Just another shitty Java middleware that never amounted to anything, 200000 lines of code that don't express even a handful of ideas.

Wow, that's frustrating code. I feel vindicated in using an ultrawide to code with. When I mentioned on here I use it because sometimes you have to work on code with super-deep indents I got downvoted to negative infinity for shitty code management.