Hardcoded default providers for asynchronous channel and file system

Alan Bateman Alan.Bateman at oracle.com
Sun Nov 6 10:16:05 PST 2011


On 04/11/2011 08:26, Jonathan Lu wrote:
> Hi nio-dev,
>
> I found some hardcoded default providers in following two classes of 
> nio module,
> sun/nio/ch/DefaultAsynchronousChannelProvider.java
> sun/nio/fs/DefaultFileSystemProvider.java
>
> On Unix platforms, these default providers will read the value of 
> 'os.name' and construct platform specific provider accordingly.
> For example, sun.nio.fs.SolarisFileSystemProvider is created if 
> os.name equals "SunOS".
> So several lines have to be modified to these class files when I try 
> to port OpenJDK onto a new platform other than Linux and Solaris.
>
> So how about change this behavior to a more flexible approach? not 
> depending on os.name.
>
> I prefer to generating the providers during compiling time in makefile 
> as what has been done for nio buffers and have already got a patch 
> works in this way. Of course, there're also other ways to do this, 
> such as use a predefined property or a configuration file.
> Any other ideas?
The other one is 
src/solaris/classes/sun/nio/ch/DefaultSelectorProvider.java which 
selects the /dev/poll or epoll SelectorProvider depending on whether we 
are running on Solaris or Linux.

I agree we should re-visit this. One other benefit is that it fixes 
another issue that we have on Solaris and Linux whereby classes for the 
other platform are compiled and end up in rt.jar. It's not  significant 
from a footprint perspective but confusing to see Solaris specific 
classes in the Linux rt.jar (and vice versa).

I think build time would be the right place to select the factory class 
and we should avoid consulting a property or configuration file at 
runtime. So I would suggest go ahead and publish your patch for 
discussion here.

-Alan


More information about the nio-dev mailing list