Hardcoded default providers for asynchronous channel and file system

Jonathan Lu luchsh at linux.vnet.ibm.com
Tue Nov 15 03:20:57 PST 2011


Hi Alan,

On 11/15/2011 03:09 AM, Alan Bateman wrote:
> On 11/11/2011 08:48, Jonathan Lu wrote:
>> :
>>
>>
>> For DefaultFileSystemProvider, the logic for Linux and Solaris 
>> platforms are a bit different from Windows platform.
>> Class.forName() and Class.newInstance() are used to create 
>> DefaultFileSystemProvider on Linux and Solaris, but only one simple 
>> new statement found for Windows platform. Is there any particular 
>> reason to place such a different logic here?
>> I do not see any and think the same approach for 
>> DefaultAsynchronousChannelProvider can also be applied here, please 
>> fix me if incorrect.
> The reason it was done this way was to avoid the static dependencies 
> as we don't want Solaris specific classes being compiled when doing 
> Linux builds and vice versa.

But why is the Class.forName() style applied only for 
DefaultFileSystemProvider, not for all the default providers? if not 
particular reason, what about just change both 
DefaultAsynchronousChannelProvider and DefaultSelectorProvider to follow 
this style ?

>
>>
>> Okay :)
>> But for current layout if adopt this approach, there'll be total 9 
>> additional template files instead of 3 additional scripts. And the 
>> templates of the same provider for different platforms are almost the 
>> same.
> Actually you could get away with 6 as this is only needed for 
> Solaris/Linux because they share the same directory.
>> Yes, 2.6 or newer linux kernel should be the default assumption here 
>> just like what the LinuxFileSystem did. So EPollSelectorProvider will 
>> be the only result returned on Linux platform, PollSelectorProvider 
>> will not be used any more.
> That's right although it may have to continue to be used on the Mac 
> until the kqueue based Selector passes all tests.
>
>>
>> But I do find a testcase  jdk/test/sun/nio/ch/SelProvider.java which 
>> will test old Linux,  I think it should be changed accordingly, right?
> Good catch, this should be changed too.
>
>> :
>>
>> In order to split the complexity out of scripts, what would you think 
>> about composing a common template file for all providers and all the 
>> platforms?
> That would be better, so it would be something like the following 
> invoked in the build:
>
> genProviderFactory \
>   sun.nio.ch.EPollSelectorProvider \
>   sun.nio.ch.LinuxAsynchronousChannelProvider \
>   sun.nio.fs.LinuxFileSystemProvider
>
> and it would generate something like sun.nio.ProviderFactory that 
> defines 3 static methods to create the providers.
>
> I think I could live with that.
>
> -Alan
>
- Jonathan



More information about the nio-dev mailing list