Hacker News Reader

Comment by pjmlp | Hacker News Reader

First class support on the JVM, instead of .class boilerplate emulating the feature, usable only for Kotlin.

The example I think is compelling is JDBC.

Nearly all SQL Database access goes through it and it won't be rewritten in any practical time scale. It can't be meaningfully async without a rewrite and kotlin's coroutines can't change that.

With virtual threads that synchronous api can be used at the performance level of what a hypothetical JDBC rewite would give.

(Not that you want to hit your DB that much, but you know what I mean. You don't need to specially wrap or bundle apis to get into an async call juggle.)

There are already some efforts in that direction. You can check out r2dbc and the many vert.x sql clients. While they're not really jdbc, they're fully async like you described.

I was investigating this lately, and as you say, they are "efforts", and while laudable, I wouldn't go so far as to call them solutions. There are open issues/caveats as a result of the async model.

I do think there is something great about being able to continue to leverage existing JDBC-related tooling, given that it already exists.

And the importance of this first class support cannot be overstated. It means: - meaningful complete stacktraces - debugger support - all blocking libraries get the benefits of async code automatically [1] - all monitoring features of the platform work - profilers get more useful again - less mental overhead when programming, i.e. simplicity

[1]: With one caveat: Libraries which call directly into blocking native calls do not become async automatically. But they are very rare on the Java platform.

Reply on news.ycombinator.com