Thanks for all the insight Lukas. I'm excited for Loom as well and have been watching Ron's work keenly. I don't think they're at the stage to set a timeline, so I don't know if it makes sense to plan around it yet.
To the best of my knowledge, as a coroutine/green thread system, Loom won't attempt to solve the problem of fusing multiple connections into a single epoll. Any "async" db connector will have to solve that itself anyway, though Loom would would greatly simplify an efficient implementation and the efficient use of one. I'll read more into R2DBC. On Monday, June 24, 2019 at 1:05:41 AM UTC-7, Lukas Eder wrote: > > > > On Monday, June 24, 2019 at 9:41:44 AM UTC+2, Lukas Eder wrote: >> >> >> At some point, we'll get this "right", even in Java. And I have a lot >> more hopes for project Loom than for these API driven solutions, because >> solving asynchronicity and reactiveness with APIs alone is going to clutter >> client code with tons of uninteresting and difficult to reason about >> infrastructure code. This is also something Oracle is thinking about. >> Should they push ADBA and make it *both* asynchronous (CompletionStage) and >> reactive (Flow), or should they bet on upgrading JDBC through Loom? Because >> if Loom keeps up with its promises, using JDBC in a coroutine style way >> seems *much* more compelling than relying on new SPIs and APIs. >> >> > Some context for project Loom: > https://www.infoq.com/presentations/continuations-java/ > -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jooq-user/f3376231-a23a-4078-bbde-9da194664f8f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
