-
Enhancement
-
Resolution: Won't Fix
-
P4
-
None
-
1.4.1, 5.0
-
generic, x86
-
generic, windows_xp
The way the current java.nio.channels.spi.SelectorProvider implemented doesnt allow any application to extend the default selector provider functionality offered by JDK.
The currrent method of setting system propoerty java.nio.channels.spi.SelectorProvider forces user to implement all nio socket functionality on their own.
The only way to get the default provider object is by calling SelectorProvider.provider(). However this call sets a singleton to be used as SelectorProvider. So, the very first time the SelectorProvider.provider() is called, the provider singleton object is set. This would disallow wrapping the provider in a custom class.
There is no system property that user can access to obtain the default selector provider class name of JDK. So, application cannot use reflection to create the provider and then wrap in its on custom implementation.
The currrent method of setting system propoerty java.nio.channels.spi.SelectorProvider forces user to implement all nio socket functionality on their own.
The only way to get the default provider object is by calling SelectorProvider.provider(). However this call sets a singleton to be used as SelectorProvider. So, the very first time the SelectorProvider.provider() is called, the provider singleton object is set. This would disallow wrapping the provider in a custom class.
There is no system property that user can access to obtain the default selector provider class name of JDK. So, application cannot use reflection to create the provider and then wrap in its on custom implementation.
- duplicates
-
JDK-4819087 Monitoring traffic through NIO Channel
- Closed