|Re: [jakartaee-platform-dev] about Virtual Threads in Jakarta EE 11|
_______________________________________________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.From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> on behalf of ma zhen <mz1999@xxxxxxxxx>
Sent: Sunday, February 12, 2023 12:04 AM
To: jakartaee-platform-dev@xxxxxxxxxxx <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: [jakartaee-platform-dev] about Virtual Threads in Jakarta EE 11
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!
jakartaee-platform-dev mailing list
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
Back to the top