Jonas Konrad

Yea I made this PR draft because I wanted to try to change it at a higher level (in ConversionService) but I dont think thats viable, so this PR should...

no it's still on my todo. just not this approach

The general idea is correct but implementing a custom reactive publisher is complicated wrt concurrency, backpressure, nesting etc.. We regularly have bugs like #10017 even with simpler code than this....

yea this test case with `@RequestScope` has the same problem as `ServerRequestContext`. We can't guarantee that the context will always propagate

it would have to re-encode to utf-16 if there is non-latin1 input, yes. this is also what stringbuilder does though, and i think it may be worth it. will depend...

okay i've done some preliminary benchmarking in https://github.com/yawkat/jackson-core/tree/compact-strings . it is very interesting. The benchmark results without StringBuilder: ``` Benchmark (alphabet) (length) Mode Cnt Score Error Units TextBufferBenchmark.parseBytes ASCII 10...

Another option I just thought of would be to use byte[] containing raw UTF-8, instead of StringBuilder. The Strings would then be constructed directly from the byte array, either as...

Thanks for the report!

Moving everything to virtual threads by default isn't happening anytime soon. What you could instead try is add an empty request filter that has `@ExecuteOn(BLOCKING)`. I think this should move...

i think it makes sense in the long term though. we already have some arg binders that kind of block, such as `@Body`, which use weird PendingRequestBindingResult api. i think...