Hardcoded default providers for asynchronous channel and file system

[Jonathan Lu]

Hello Alan, nio-dev,

Any comments on this patch?

Regards!
- Jonathan!

On 11/16/2011 06:31 PM, Jonathan Lu wrote:
> 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.
>>
>>
>>>
>>> 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
>>
>>
> Hi Alan,
>
> Here's another patch which is similar to your approach, but the 
> difference here is that it is trying to isolate the naming differences 
> into one single script instead of introducing a factory class. I think 
> if the logic is the same for all the platforms, it would be better if 
> there is a map (the branch statements from the script) to link each 
> provider name to the provider source.
>
> Several benefits of this patch,
> 1, Only several branch statements of one script file need to be 
> adjusted if a new platform is going to be supported. And the script 
> file is pretty clear to read.
> 2, Generated default providers only contains the code for target 
> platform, no more os.name checking.
> 3, Unchanged default provider APIs for other parts of the class 
> library, such as in 
> java/rmi/activation/rmidViaInheritedChannel/RmidViaInheritedChannel.java.
> 4, Compiling time complexity is reduced to only one simple shell 
> script file.
>
> Any comments on this approach?
>
> - Jonathan