Native methods and virtual threads

[Ron Pressler]

The official statement is that we address problems in order of priority based in part on how frequently our users actually encounter them. If blocking native method end up posing an actual problem that many users encounter in the field, of course we’ll try to address it. But given that not every blocking native function poses an issue in the first place and that compensation cannot make every use of blocking methods work well with virtual threads, we need to see what kind of problems people actually encounter before designing solutions for them. At the moment we’re already busy enough working on problems we do understand.

But let me say that again: If blocking native calls end up causing a problem that affects many people, of course we will study it and address it.

— Ron



> On 14 Jul 2023, at 21:38, Brian S O'Neill <bronee at gmail.com> wrote:
> 
> That's a very bold claim. Every native library I've written or had to interact with has performed blocking at some level, whether it be file I/O, network I/O, or mutexes. Many popular embedded databases are in fact not written in Java, and the native calls can block. JDBC drivers which rely on native code also block.
> 
> If the official statement is to not address the problem, then I'm close to reaching the conclusion that virtual threads might have been a mistake. It adds complexity to the Java platform, and native methods now have to ask the question, "what color is my thread?"
> 
> If I'm writing a new service, and I have complete control over what native libraries it depends on, I might conclude that virtual threads are a good choice. But as the service evolves, I might want to start depending on native libraries that provide needed functionality. If they perform blocking operations, I might need to wrap the library with a message passing queue, which just adds overhead and complexity. If the advice is to stop using virtual threads at this point, I could have made that decision from day one. And it seems that's the safest option.
> 
> 
> On 2023-07-14 01:09 PM, Ron Pressler wrote:
>> Because blocking native calls in Java are not very common (at least outside of the JDK itself) and because using platform threads in Java is easy we have no short-term plan for making very frequent blocking native calls work in perfect harmony with virtual threads in general, nor are we aware of a pressing need for that. When we find significant demand for code that uses blocking native calls extensively and yet still gains significant benefit from the use of virtual threads, we will adjust the matter's priority accordingly.