Hardcoded default providers for asynchronous channel and file system

[Jonathan Lu]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: default_providers.patch
Type: text/x-patch
Size: 22036 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20111116/12f7cfee/default_providers.patch