I suspect most of the impact is really in the implementation layer rather than the API layer. This is mostly because traditionally Jakarta EE has abstracted multi-threading anyway.
The most concrete end result may be that we rethink priorities in terms of adding more reactive/non-blocking/NIO APIs into the platform. That said, one area of exploration is whether there is a need to have a managed version of virtual threads. I suspect since they are not as heavyweight, using them directly in Jakarta EE applications is fine.
I am curious too what vendor innovations/analysis may happen though.
I watched the video of the Jakarta EE Monthly Platform Architecture Call on February 7th. https://www.youtube.com/watch?v=UD1ecWJMljY
According to my understanding, current application servers use the NIO framework to handle network requests, for example, glassfish uses grizzly. When Virtual Threads is introduced, it will have a big impact on the implementation architecture of existing application servers. Glassfish will abandon grizzly and re-implement it with a blocking API.
It seems that this meeting did not discuss how Jakarta EE 11 will use Virtual Threads. I would like to know what the working group thinks about it. Thanks!
Best regards,
mazhen
