From luchsh at linux.vnet.ibm.com Fri Nov 4 01:26:13 2011 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Fri, 04 Nov 2011 16:26:13 +0800 Subject: Hardcoded default providers for asynchronous channel and file system Message-ID: <4EB3A1A5.6020705@linux.vnet.ibm.com> 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? Cheers Jonathan From Alan.Bateman at oracle.com Sun Nov 6 10:16:05 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 06 Nov 2011 18:16:05 +0000 Subject: Hardcoded default providers for asynchronous channel and file system In-Reply-To: <4EB3A1A5.6020705@linux.vnet.ibm.com> References: <4EB3A1A5.6020705@linux.vnet.ibm.com> Message-ID: <4EB6CEE5.30108@oracle.com> 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 From luchsh at linux.vnet.ibm.com Tue Nov 8 01:11:40 2011 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Tue, 08 Nov 2011 17:11:40 +0800 Subject: Hardcoded default providers for asynchronous channel and file system In-Reply-To: <4EB6CEE5.30108@oracle.com> References: <4EB3A1A5.6020705@linux.vnet.ibm.com> <4EB6CEE5.30108@oracle.com> Message-ID: <4EB8F24C.903@linux.vnet.ibm.com> On 11/07/2011 02:16 AM, Alan Bateman wrote: > 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 Hello Alan, Thanks for reminding! I've updated my patch to include DefaultSelectorProvider, see the attachment. And I also tried to build the patched OpenJDK8 on Linux, Windows and Solaris, the result seems OK. Could you please take a look at it? Thank you! -Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: provider.patch Type: text/x-patch Size: 27756 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20111108/0b2eeead/provider-0001.patch From forax at univ-mlv.fr Tue Nov 8 02:00:50 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 08 Nov 2011 11:00:50 +0100 Subject: Hardcoded default providers for asynchronous channel and file system In-Reply-To: <4EB6CEE5.30108@oracle.com> References: <4EB3A1A5.6020705@linux.vnet.ibm.com> <4EB6CEE5.30108@oracle.com> Message-ID: <4EB8FDD2.7000909@univ-mlv.fr> On 11/06/2011 07:16 PM, Alan Bateman wrote: > 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 Hi Alan, Hi Jonathan, I've already written a program that changes the default selector provider by changing the property before trying to access the default file system. I have no problem with the fact that the default provider class is hardcoded at build time but the property should still exist, otherwise it will break my code. If you're curious, here is why I change the default provider: http://weblogs.java.net/blog/forax/archive/2011/10/01/asyncswing R?mi From Alan.Bateman at oracle.com Tue Nov 8 02:07:52 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 08 Nov 2011 10:07:52 +0000 Subject: Hardcoded default providers for asynchronous channel and file system In-Reply-To: <4EB8FDD2.7000909@univ-mlv.fr> References: <4EB3A1A5.6020705@linux.vnet.ibm.com> <4EB6CEE5.30108@oracle.com> <4EB8FDD2.7000909@univ-mlv.fr> Message-ID: <4EB8FF78.7030205@oracle.com> On 08/11/2011 10:00, R?mi Forax wrote: > > Hi Alan, Hi Jonathan, > I've already written a program that changes the default selector provider > by changing the property before trying to access the default file system. > > I have no problem with the fact that the default provider class is > hardcoded > at build time but the property should still exist, > otherwise it will break my code. > > If you're curious, here is why I change the default provider: > http://weblogs.java.net/blog/forax/archive/2011/10/01/asyncswing I haven't looked at the patch yet (might be a few days) but the system property to override the default provider shouldn't be impacted. It's really only sun.nio.ch.{DefaultSelectorProvider,DefaultAsynchronousChannelProvider} and sun.nio.fs.DefaultFileSystemProvider that need to be touched. This is why get used if the default provider isn't specified via a system property (or the other specified lookup mechanism). A simply rename or sed replacement in the build should do it. -Alan. From forax at univ-mlv.fr Tue Nov 8 02:12:09 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 08 Nov 2011 11:12:09 +0100 Subject: Hardcoded default providers for asynchronous channel and file system In-Reply-To: <4EB8FF78.7030205@oracle.com> References: <4EB3A1A5.6020705@linux.vnet.ibm.com> <4EB6CEE5.30108@oracle.com> <4EB8FDD2.7000909@univ-mlv.fr> <4EB8FF78.7030205@oracle.com> Message-ID: <4EB90079.6010108@univ-mlv.fr> On 11/08/2011 11:07 AM, Alan Bateman wrote: > On 08/11/2011 10:00, R?mi Forax wrote: >> >> Hi Alan, Hi Jonathan, >> I've already written a program that changes the default selector >> provider >> by changing the property before trying to access the default file >> system. >> >> I have no problem with the fact that the default provider class is >> hardcoded >> at build time but the property should still exist, >> otherwise it will break my code. >> >> If you're curious, here is why I change the default provider: >> http://weblogs.java.net/blog/forax/archive/2011/10/01/asyncswing > I haven't looked at the patch yet (might be a few days) but the system > property to override the default provider shouldn't be impacted. It's > really only > sun.nio.ch.{DefaultSelectorProvider,DefaultAsynchronousChannelProvider} and > sun.nio.fs.DefaultFileSystemProvider that need to be touched. This is > why get used if the default provider isn't specified via a system > property (or the other specified lookup mechanism). A simply rename or > sed replacement in the build should do it. Ok, I understand now, thanks for the explanation. > > -Alan. R?mi From Alan.Bateman at oracle.com Thu Nov 10 06:33:05 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 10 Nov 2011 14:33:05 +0000 Subject: Hardcoded default providers for asynchronous channel and file system In-Reply-To: <4EB8F24C.903@linux.vnet.ibm.com> References: <4EB3A1A5.6020705@linux.vnet.ibm.com> <4EB6CEE5.30108@oracle.com> <4EB8F24C.903@linux.vnet.ibm.com> Message-ID: <4EBBE0A1.7070801@oracle.com> On 08/11/2011 09:11, Jonathan Lu wrote: > > Hello Alan, > > Thanks for reminding! I've updated my patch to include > DefaultSelectorProvider, see the attachment. > And I also tried to build the patched OpenJDK8 on Linux, Windows and > Solaris, the result seems OK. > Could you please take a look at it? I finally got a chance to look at this. My only concern with is that adds quite a bit of complexity to the build. From a portability point of view (the original objective) then it means editing three additional scripts for each platform too. What would you think about making it a lot simpler with something like: ifneq ($(PLATFORM),windows) $(GENSRCDIR)/sun/nio/fs/DefaultFileSystemProvider.java: \ $(PLATFORM_SRC)/classes/sun/nio/fs/DefaultFileSystemProvider.java.$(PLATFORM) $(install-file) clean:: $(RM) $(GENSRCDIR)/sun/nio/fs/DefaultFileSystemProvider.java endif One benefit of this is that it would be trivial to change in the event that there were separate src/linux and src/solaris directories (BTW: don't read anything into this comment but at some point I think we should re-visit the current layout). One other comment is that you've retained the code to choose the SelectorProvider implementation based on the Linux kernel. I think we should just drop this check as it's unlikely that anyone is porting and target ancient 2.4 kernels now. -Alan. From luchsh at linux.vnet.ibm.com Fri Nov 11 00:48:13 2011 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Fri, 11 Nov 2011 16:48:13 +0800 Subject: Hardcoded default providers for asynchronous channel and file system In-Reply-To: <4EBBE0A1.7070801@oracle.com> References: <4EB3A1A5.6020705@linux.vnet.ibm.com> <4EB6CEE5.30108@oracle.com> <4EB8F24C.903@linux.vnet.ibm.com> <4EBBE0A1.7070801@oracle.com> Message-ID: <4EBCE14D.2090305@linux.vnet.ibm.com> Hi Alan, Thank you for reviewing. Indeed my patch will bring some complexity to the build time, but I think we'd better treat the three providers separately since they are not of the exactly same type. For DefaultAsynchronousChannelProvider, the logic for all the platforms are the same except for provider's name. If use your approach, following three template files will be created for each platform: DefaultAsynchronousChannelProvider.java.windows DefaultAsynchronousChannelProvider.java.linux DefaultAsynchronousChannelProvider.java.solaris But the only difference for them is one line containing the provider class name, so will it be much clearer if we dynamically generate these these files from one script or one template? 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. On 11/10/2011 10:33 PM, Alan Bateman wrote: > On 08/11/2011 09:11, Jonathan Lu wrote: >> >> Hello Alan, >> >> Thanks for reminding! I've updated my patch to include >> DefaultSelectorProvider, see the attachment. >> And I also tried to build the patched OpenJDK8 on Linux, Windows and >> Solaris, the result seems OK. >> Could you please take a look at it? > I finally got a chance to look at this. > > My only concern with is that adds quite a bit of complexity to the > build. From a portability point of view (the original objective) then > it means editing three additional scripts for each platform too. > > What would you think about making it a lot simpler with something like: > > ifneq ($(PLATFORM),windows) > > $(GENSRCDIR)/sun/nio/fs/DefaultFileSystemProvider.java: \ > > $(PLATFORM_SRC)/classes/sun/nio/fs/DefaultFileSystemProvider.java.$(PLATFORM) > $(install-file) > > clean:: > $(RM) $(GENSRCDIR)/sun/nio/fs/DefaultFileSystemProvider.java > > endif > > One benefit of this is that it would be trivial to change in the event > that there were separate src/linux and src/solaris directories (BTW: > don't read anything into this comment but at some point I think we > should re-visit the current layout). > 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. > One other comment is that you've retained the code to choose the > SelectorProvider implementation based on the Linux kernel. I think we > should just drop this check as it's unlikely that anyone is porting > and target ancient 2.4 kernels now. 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. 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? Moreover beside this test case, I do not see any other place where PollSelectorProvider is used, so shall the PollSelectorProvider and PollSelectorProviderImpl classes be completely removed from JDK8 repository? After this kernel version change the logic of DefaultSelectorProvider will be the same as DefaultAsynchronousChannelProvider. With above analysis, if DefaultSelectorProvider and DefaultFileSystemProvider are all changed to the same logic as DefaultAsynchronousChannelProvider, the condition here will be much simpler: All the default provider classes for all three platforms are of the same logic except for some naming differences! 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? all we need to do is to replace the place-holder names with actual values for each provider and each platform. This approach will introduce one template file or one script file :). Regards! -Jonathan Lu > -Alan. From spoole at linux.vnet.ibm.com Mon Nov 14 04:37:39 2011 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Mon, 14 Nov 2011 12:37:39 +0000 Subject: Hardcoded default providers for asynchronous channel and file system In-Reply-To: <4EBCE14D.2090305@linux.vnet.ibm.com> References: <4EB3A1A5.6020705@linux.vnet.ibm.com> <4EB6CEE5.30108@oracle.com> <4EB8F24C.903@linux.vnet.ibm.com> <4EBBE0A1.7070801@oracle.com> <4EBCE14D.2090305@linux.vnet.ibm.com> Message-ID: <1321274259.3678.13.camel@jazzette> On Fri, 2011-11-11 at 16:48 +0800, Jonathan Lu wrote: I do think that Alan's approach is a more cross platform solution - since to support a new platform one would only have to add in a new file with the matching platform suffix. The fact that some of these files might be very similar could be dealt with with the right sort of refactoring and having common, abstract parent classes. Having said that I don't actually like having the platform name as a suffix as it makes searching just a little bit more complicated. I do wish we could find a way to keep the .java suffix. What are the reasons for not making the platform (or equivalent) part of the name? - ie WindowsDefaultAsynchronousChannelProvider.java LinuxDefaultAsynchronousChannelProvider.java SolarisDefaultAsynchronousChannelProvider.java > Hi Alan, > > Thank you for reviewing. > > Indeed my patch will bring some complexity to the build time, but I > think we'd better treat the three providers separately since they are > not of the exactly same type. > > For DefaultAsynchronousChannelProvider, the logic for all the platforms > are the same except for provider's name. If use your approach, following > three template files will be created for each platform: > DefaultAsynchronousChannelProvider.java.windows > DefaultAsynchronousChannelProvider.java.linux > DefaultAsynchronousChannelProvider.java.solaris > But the only difference for them is one line containing the provider > class name, so will it be much clearer if we dynamically generate these > these files from one script or one template? > > 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. > > On 11/10/2011 10:33 PM, Alan Bateman wrote: > > On 08/11/2011 09:11, Jonathan Lu wrote: > >> > >> Hello Alan, > >> > >> Thanks for reminding! I've updated my patch to include > >> DefaultSelectorProvider, see the attachment. > >> And I also tried to build the patched OpenJDK8 on Linux, Windows and > >> Solaris, the result seems OK. > >> Could you please take a look at it? > > I finally got a chance to look at this. > > > > My only concern with is that adds quite a bit of complexity to the > > build. From a portability point of view (the original objective) then > > it means editing three additional scripts for each platform too. > > > > What would you think about making it a lot simpler with something like: > > > > ifneq ($(PLATFORM),windows) > > > > $(GENSRCDIR)/sun/nio/fs/DefaultFileSystemProvider.java: \ > > > > $(PLATFORM_SRC)/classes/sun/nio/fs/DefaultFileSystemProvider.java.$(PLATFORM) > > $(install-file) > > > > clean:: > > $(RM) $(GENSRCDIR)/sun/nio/fs/DefaultFileSystemProvider.java > > > > endif > > > > One benefit of this is that it would be trivial to change in the event > > that there were separate src/linux and src/solaris directories (BTW: > > don't read anything into this comment but at some point I think we > > should re-visit the current layout). > > > 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. > > One other comment is that you've retained the code to choose the > > SelectorProvider implementation based on the Linux kernel. I think we > > should just drop this check as it's unlikely that anyone is porting > > and target ancient 2.4 kernels now. > 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. > > 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? > Moreover beside this test case, I do not see any other place where > PollSelectorProvider is used, so shall the PollSelectorProvider and > PollSelectorProviderImpl classes be completely removed from JDK8 repository? > > After this kernel version change the logic of DefaultSelectorProvider > will be the same as DefaultAsynchronousChannelProvider. > > > With above analysis, if DefaultSelectorProvider and > DefaultFileSystemProvider are all changed to the same logic as > DefaultAsynchronousChannelProvider, the condition here will be much simpler: > All the default provider classes for all three platforms are of > the same logic except for some naming differences! > > 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? > all we need to do is to replace the place-holder names with actual > values for each provider and each platform. This approach will introduce > one template file or one script file :). > > Regards! > -Jonathan Lu > > > -Alan. > From Alan.Bateman at oracle.com Mon Nov 14 11:09:59 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Nov 2011 19:09:59 +0000 Subject: Hardcoded default providers for asynchronous channel and file system In-Reply-To: <4EBCE14D.2090305@linux.vnet.ibm.com> References: <4EB3A1A5.6020705@linux.vnet.ibm.com> <4EB6CEE5.30108@oracle.com> <4EB8F24C.903@linux.vnet.ibm.com> <4EBBE0A1.7070801@oracle.com> <4EBCE14D.2090305@linux.vnet.ibm.com> Message-ID: <4EC16787.7090100@oracle.com> 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 From luchsh at linux.vnet.ibm.com Tue Nov 15 03:20:57 2011 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Tue, 15 Nov 2011 19:20:57 +0800 Subject: Hardcoded default providers for asynchronous channel and file system In-Reply-To: <4EC16787.7090100@oracle.com> References: <4EB3A1A5.6020705@linux.vnet.ibm.com> <4EB6CEE5.30108@oracle.com> <4EB8F24C.903@linux.vnet.ibm.com> <4EBBE0A1.7070801@oracle.com> <4EBCE14D.2090305@linux.vnet.ibm.com> <4EC16787.7090100@oracle.com> Message-ID: <4EC24B19.8090600@linux.vnet.ibm.com> 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 From Alan.Bateman at oracle.com Tue Nov 15 11:44:05 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Nov 2011 19:44:05 +0000 Subject: Hardcoded default providers for asynchronous channel and file system In-Reply-To: <4EC24B19.8090600@linux.vnet.ibm.com> References: <4EB3A1A5.6020705@linux.vnet.ibm.com> <4EB6CEE5.30108@oracle.com> <4EB8F24C.903@linux.vnet.ibm.com> <4EBBE0A1.7070801@oracle.com> <4EBCE14D.2090305@linux.vnet.ibm.com> <4EC16787.7090100@oracle.com> <4EC24B19.8090600@linux.vnet.ibm.com> Message-ID: <4EC2C105.9010007@oracle.com> On 15/11/2011 11:20, Jonathan Lu wrote: > > 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 ? All three could use reflection and that would address the static dependency issue, but it wouldn't address the portability issue in that each of the providers would require to be changed when porting to another platform. -Alan. From luchsh at linux.vnet.ibm.com Wed Nov 16 02:31:03 2011 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Wed, 16 Nov 2011 18:31:03 +0800 Subject: Hardcoded default providers for asynchronous channel and file system In-Reply-To: <4EC16787.7090100@oracle.com> References: <4EB3A1A5.6020705@linux.vnet.ibm.com> <4EB6CEE5.30108@oracle.com> <4EB8F24C.903@linux.vnet.ibm.com> <4EBBE0A1.7070801@oracle.com> <4EBCE14D.2090305@linux.vnet.ibm.com> <4EC16787.7090100@oracle.com> Message-ID: <4EC390E7.3060608@linux.vnet.ibm.com> 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 From chris.hegarty at oracle.com Fri Nov 18 02:38:49 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 18 Nov 2011 10:38:49 +0000 Subject: Suppress creation of SocksSocketImpl in SocketAdaptor's constructor In-Reply-To: References: Message-ID: <4EC635B9.3030007@oracle.com> Kris, This issue would be more appropriate on the net-dev or nio-dev mailing lists. So, I'll cross post it and bcc off jdk8-dev. Thanks, -Chris. On 11/18/11 08:22 AM, ???? wrote: > Hi all, > > I'd like to propose the following change to JDK's sun.nio.ch.SocketAdaptor: > > In OpenJDK 6, 7 and 8, sun.nio.ch.SocketAdaptor is used to adapt a SocketChannelImpl to a java.net.Socket. > > A comment in the constructor of SocketAdaptor says "super will create a useless impl", but it actually doesn't have to. AFAICT the SocksSocketImpl instance created here really isn't used at all in SocketAdaptor, unless someone invokes non-public methods on java.net.Socket via reflection. > > The attached patch is to get rid of creation of the useless SocksSocketImpl. > > At a glance, creating a useless SocksSocketImpl for every SocketAdaptor seems innocent. But that's not the case when the allocation rate/heap memory pressure is high. SocksSocketImpl has a finalizer (inherited from PlainSocketImpl), and when: > * old generation is large > * there are a lot of ready-to-die SocksSocketImpl instances > these instances can be queued up in the finalizer queue, which increases the heap pressure. > > In one of our Hadoop NameNode nodes in production, excessive SocksSocketImpl instances had been causing frequent CMS collections + long reference processing pause. Using this patch helps side-steping the problem. > > I don't have a bug ID for this yet. Could anyone kindly open a bug for this? > > Regards, > Kris Mok > Software Engineer, Taobao (http://www.taobao.com) > > ________________________________ > This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. > > ??????(????????????)???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? From chris.hegarty at oracle.com Fri Nov 18 02:44:09 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 18 Nov 2011 10:44:09 +0000 Subject: Fwd: Re: Suppress creation of SocksSocketImpl in SocketAdaptor's constructor Message-ID: <4EC636F9.9020807@oracle.com> -------- Original Message -------- Subject: Re: Suppress creation of SocksSocketImpl in SocketAdaptor's constructor Date: Fri, 18 Nov 2011 16:38:28 +0800 From: Krystal Mok To: ???? CC: jdk8-dev at openjdk.java.net Oops, looks like my company email stripped the attachment. Here's that patch again: diff -r 00e2c88e2234 src/share/classes/sun/nio/ch/SocketAdaptor.java --- a/src/share/classes/sun/nio/ch/SocketAdaptor.java Thu Nov 17 10:46:02 2011 -0800 +++ b/src/share/classes/sun/nio/ch/SocketAdaptor.java Fri Nov 18 15:37:20 2011 +0800 @@ -57,13 +57,17 @@ // Timeout "option" value for reads private volatile int timeout = 0; - // ## super will create a useless impl - private SocketAdaptor(SocketChannelImpl sc) { + private SocketAdaptor(SocketChannelImpl sc) throws SocketException { + super((SocketImpl) null); this.sc = sc; } public static Socket create(SocketChannelImpl sc) { - return new SocketAdaptor(sc); + try { + return new SocketAdaptor(sc); + } catch (SocketException e) { + throw new RuntimeException("should not reach here"); + } } public SocketChannel getChannel() { - Kris 2011/11/18 ???? > Hi all, > > I'd like to propose the following change to JDK's sun.nio.ch.SocketAdaptor: > > In OpenJDK 6, 7 and 8, sun.nio.ch.SocketAdaptor is used to adapt a > SocketChannelImpl to a java.net.Socket. > > A comment in the constructor of SocketAdaptor says "super will create a > useless impl", but it actually doesn't have to. AFAICT the SocksSocketImpl > instance created here really isn't used at all in SocketAdaptor, unless > someone invokes non-public methods on java.net.Socket via reflection. > > The attached patch is to get rid of creation of the useless > SocksSocketImpl. > > At a glance, creating a useless SocksSocketImpl for every SocketAdaptor > seems innocent. But that's not the case when the allocation rate/heap > memory pressure is high. SocksSocketImpl has a finalizer (inherited from > PlainSocketImpl), and when: > * old generation is large > * there are a lot of ready-to-die SocksSocketImpl instances > these instances can be queued up in the finalizer queue, which increases > the heap pressure. > > In one of our Hadoop NameNode nodes in production, excessive > SocksSocketImpl instances had been causing frequent CMS collections + long > reference processing pause. Using this patch helps side-steping the problem. > > I don't have a bug ID for this yet. Could anyone kindly open a bug for > this? > > Regards, > Kris Mok > Software Engineer, Taobao (http://www.taobao.com) > > ________________________________ > This email (including any attachments) is confidential and may be legally > privileged. If you received this email in error, please delete it > immediately and do not copy it or use it for any purpose or disclose its > contents to any other person. Thank you. > > > ??????(????????????)???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? > From chris.hegarty at oracle.com Fri Nov 18 02:57:21 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 18 Nov 2011 10:57:21 +0000 Subject: Fwd: Re: Suppress creation of SocksSocketImpl in SocketAdaptor's constructor In-Reply-To: <4EC636F9.9020807@oracle.com> References: <4EC636F9.9020807@oracle.com> Message-ID: <4EC63A11.9050302@oracle.com> Hi Kris, I think this change should be fine, but I would like Alan to comment also. Thanks, -Chris. On 11/18/11 10:44 AM, Chris Hegarty wrote: > > > -------- Original Message -------- > Subject: Re: Suppress creation of SocksSocketImpl in SocketAdaptor's > constructor > Date: Fri, 18 Nov 2011 16:38:28 +0800 > From: Krystal Mok > To: ???? > CC: jdk8-dev at openjdk.java.net > > Oops, looks like my company email stripped the attachment. > Here's that patch again: > > diff -r 00e2c88e2234 src/share/classes/sun/nio/ch/SocketAdaptor.java > --- a/src/share/classes/sun/nio/ch/SocketAdaptor.java Thu Nov 17 10:46:02 > 2011 -0800 > +++ b/src/share/classes/sun/nio/ch/SocketAdaptor.java Fri Nov 18 15:37:20 > 2011 +0800 > @@ -57,13 +57,17 @@ > // Timeout "option" value for reads > private volatile int timeout = 0; > > - // ## super will create a useless impl > - private SocketAdaptor(SocketChannelImpl sc) { > + private SocketAdaptor(SocketChannelImpl sc) throws SocketException { > + super((SocketImpl) null); > this.sc = sc; > } > > public static Socket create(SocketChannelImpl sc) { > - return new SocketAdaptor(sc); > + try { > + return new SocketAdaptor(sc); > + } catch (SocketException e) { > + throw new RuntimeException("should not reach here"); > + } > } > > public SocketChannel getChannel() { > > > - Kris > > 2011/11/18 ???? > >> Hi all, >> >> I'd like to propose the following change to JDK's sun.nio.ch.SocketAdaptor: >> >> In OpenJDK 6, 7 and 8, sun.nio.ch.SocketAdaptor is used to adapt a >> SocketChannelImpl to a java.net.Socket. >> >> A comment in the constructor of SocketAdaptor says "super will create a >> useless impl", but it actually doesn't have to. AFAICT the SocksSocketImpl >> instance created here really isn't used at all in SocketAdaptor, unless >> someone invokes non-public methods on java.net.Socket via reflection. >> >> The attached patch is to get rid of creation of the useless >> SocksSocketImpl. >> >> At a glance, creating a useless SocksSocketImpl for every SocketAdaptor >> seems innocent. But that's not the case when the allocation rate/heap >> memory pressure is high. SocksSocketImpl has a finalizer (inherited from >> PlainSocketImpl), and when: >> * old generation is large >> * there are a lot of ready-to-die SocksSocketImpl instances >> these instances can be queued up in the finalizer queue, which increases >> the heap pressure. >> >> In one of our Hadoop NameNode nodes in production, excessive >> SocksSocketImpl instances had been causing frequent CMS collections + long >> reference processing pause. Using this patch helps side-steping the problem. >> >> I don't have a bug ID for this yet. Could anyone kindly open a bug for >> this? >> >> Regards, >> Kris Mok >> Software Engineer, Taobao (http://www.taobao.com) >> >> ________________________________ >> This email (including any attachments) is confidential and may be legally >> privileged. If you received this email in error, please delete it >> immediately and do not copy it or use it for any purpose or disclose its >> contents to any other person. Thank you. >> >> >> ??????(????????????)???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? >> From Alan.Bateman at oracle.com Fri Nov 18 03:38:47 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 18 Nov 2011 11:38:47 +0000 Subject: Fwd: Re: Suppress creation of SocksSocketImpl in SocketAdaptor's constructor In-Reply-To: <4EC63A11.9050302@oracle.com> References: <4EC636F9.9020807@oracle.com> <4EC63A11.9050302@oracle.com> Message-ID: <4EC643C7.9040909@oracle.com> On 18/11/2011 10:57, Chris Hegarty wrote: > Hi Kris, > > I think this change should be fine, but I would like Alan to comment also. > I'm not around this week but will look at it next week. One initial comment is that the need to use the socket adapter went away in jdk7. Newer code using SocketChannel can invoke SocketChannel's bind or setOption methods directly. -Alan From Alan.Bateman at oracle.com Sat Nov 19 11:44:56 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 19 Nov 2011 19:44:56 +0000 Subject: Fwd: Re: Suppress creation of SocksSocketImpl in SocketAdaptor's constructor In-Reply-To: <4EC63A11.9050302@oracle.com> References: <4EC636F9.9020807@oracle.com> <4EC63A11.9050302@oracle.com> Message-ID: <4EC80738.2000609@oracle.com> On 18/11/2011 10:57, Chris Hegarty wrote: > Hi Kris, > > I think this change should be fine, but I would like Alan to comment also. > I looked at it in more detail and I think it should okay. Will you sponsor it? My only comment on the change is the catching of SocketException causes a RuntimeException to be thrown but that is inconsistent with other areas of this code where AssertionError or InternalError is thrown. -Alan From dmdabbs at gmail.com Sat Nov 19 12:21:14 2011 From: dmdabbs at gmail.com (David Dabbs) Date: Sat, 19 Nov 2011 14:21:14 -0600 Subject: AsynchronousDatagramChannel implementation Message-ID: <000f01cca6f8$ca45bd10$5ed13730$@com> Hello. Bug 6993126, http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6993126, indicated that >We need to remove AsynchronousDatagramChannel before jdk7 goes into lock-down mode. >This class was included for consistency reasons but was never required for scalability >or other reasons. The implementation needs work and the JCK test coverage is weak too. >We've agreed that the best thing is to remove it for jdk7 and look at it again in jdk8. ADC stayed in JDK7, but are the improvements in the jdk8 plan? What was was/is deficient about the implementation? Perhaps it is something that could be contributed. Many thanks, David From luchsh at linux.vnet.ibm.com Sun Nov 20 23:35:54 2011 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Mon, 21 Nov 2011 15:35:54 +0800 Subject: IOException from sun.nio.fs.UnixUserPrincipals.lookupName Message-ID: <4EC9FF5A.3070505@linux.vnet.ibm.com> Hi nio-dev, I got a exception from sun.nio.fs.UnixUserPrincipals.lookupName(), the stack trace looks like java.io.IOException: 12345!@#$%^&: at sun.nio.fs.UnixUserPrincipals.lookupName(UnixUserPrincipals.java:148) at sun.nio.fs.UnixUserPrincipals.lookupUser(UnixUserPrincipals.java:170) at sun.nio.fs.UnixFileSystem$LookupService$1.lookupPrincipalByName(UnixFileSystem.java:331) The expected exception ought be UserPrincipalNotFoundException instead of IOException, since my application was testing with a non-existing user. Then I found following code piece from solaris/native/sun/nio/fs/UnixNativeDispatcher.c:1005 if (res != 0 || p == NULL || p->pw_name == NULL || *(p->pw_name) == '\0') { /* not found or error */ if (errno != 0 && errno != ENOENT) throwUnixException(env, errno); } else { uid = p->pw_uid; } Seems the "throwUnixException(env, errno)" statement caused this IOException, and the actual value of errno for my application is ESRCH (3), which means "no such process". As I understand, UnixException is thrown only when error occurs instead of when user name is not found, right? Since these checks are all about the result of getpwnam_r API, so I searched the system manual and found, The Linux manual says, ERRORS 0 or ENOENT or ESRCH or EBADF or EPERM or ... The given name or uid was not found. The Solaris 11 manual even does not mention ENOENT! So does anybody know why only ENOENT is checked here? What about at least adding ESRCH to this check list as attached patch did? Regards - Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: ESRCH_check.patch Type: text/x-patch Size: 612 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20111121/d4d42d32/ESRCH_check.patch From Alan.Bateman at oracle.com Mon Nov 21 00:34:42 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 Nov 2011 08:34:42 +0000 Subject: IOException from sun.nio.fs.UnixUserPrincipals.lookupName In-Reply-To: <4EC9FF5A.3070505@linux.vnet.ibm.com> References: <4EC9FF5A.3070505@linux.vnet.ibm.com> Message-ID: <4ECA0D22.90702@oracle.com> On 21/11/2011 07:35, Jonathan Lu wrote: > > Since these checks are all about the result of getpwnam_r API, so I > searched the system manual and found, > The Linux manual says, > ERRORS > 0 or ENOENT or ESRCH or EBADF or EPERM or ... > The given name or uid was not found. > If you skip down to the Notes section of the man page then it reads: " The formulation given above under "RETURN VALUE" is from POSIX.1-2001. It does not call "not found" an error, and hence does not specify what value /errno/ might have in this situation. But that makes it impossible to recognize errors. One might argue that according to POSIX /errno/ should be left unchanged if an entry is not found. Experiments on various UNIX-like systems show that lots of different values occur in this situation: 0, ENOENT, EBADF, ESRCH, EWOULDBLOCK, EPERM and probably others" so it is hard to distinguish the "not found" case. In our experiments on Linux and Solaris with different name services (NIS, LDAP) then the current code handles all cases. So are you seeing this on AIX or have you seen it elsewhere? I'm just curious and don't have any objection to extending the errors that map to not found. I'm also curious if getgrnam0 has the same issue. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20111121/48d8bf01/attachment.html From luchsh at linux.vnet.ibm.com Mon Nov 21 00:24:08 2011 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Mon, 21 Nov 2011 16:24:08 +0800 Subject: Hardcoded default providers for asynchronous channel and file system In-Reply-To: <4EC390E7.3060608@linux.vnet.ibm.com> References: <4EB3A1A5.6020705@linux.vnet.ibm.com> <4EB6CEE5.30108@oracle.com> <4EB8F24C.903@linux.vnet.ibm.com> <4EBBE0A1.7070801@oracle.com> <4EBCE14D.2090305@linux.vnet.ibm.com> <4EC16787.7090100@oracle.com> <4EC390E7.3060608@linux.vnet.ibm.com> Message-ID: <4ECA0AA8.7060308@linux.vnet.ibm.com> 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 From luchsh at linux.vnet.ibm.com Mon Nov 21 01:50:07 2011 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Mon, 21 Nov 2011 17:50:07 +0800 Subject: IOException from sun.nio.fs.UnixUserPrincipals.lookupName In-Reply-To: <4ECA0D22.90702@oracle.com> References: <4EC9FF5A.3070505@linux.vnet.ibm.com> <4ECA0D22.90702@oracle.com> Message-ID: <4ECA1ECF.4010800@linux.vnet.ibm.com> On 11/21/2011 04:34 PM, Alan Bateman wrote: > On 21/11/2011 07:35, Jonathan Lu wrote: >> >> Since these checks are all about the result of getpwnam_r API, so I >> searched the system manual and found, >> The Linux manual says, >> ERRORS >> 0 or ENOENT or ESRCH or EBADF or EPERM or ... >> The given name or uid was not found. >> > If you skip down to the Notes section of the man page then it reads: > > " The formulation given above under "RETURN VALUE" is from > POSIX.1-2001. It does not call "not found" an error, and hence does > not specify what value /errno/ might have in this situation. But that > makes it impossible to recognize errors. One might argue that > according to POSIX /errno/ should be left unchanged if an entry is not > found. Experiments on various UNIX-like systems show that lots of > different values occur in this situation: 0, ENOENT, EBADF, ESRCH, > EWOULDBLOCK, EPERM and probably others" > > so it is hard to distinguish the "not found" case. In our experiments > on Linux and Solaris with different name services (NIS, LDAP) then the > current code handles all cases. So are you seeing this on AIX or have > you seen it elsewhere? I'm just curious and don't have any objection > to extending the errors that map to not found. I'm also curious if > getgrnam0 has the same issue. Yes, this problem was originally found on AIX platform and I just tested getgrnam_r(), it failed with the same errno as getpwnam_r(), so I think if there's an adjustment, getgrnam0 should be included too. > > -Alan. - Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20111121/bb75a02a/attachment.html From chris.hegarty at oracle.com Mon Nov 21 02:02:37 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 21 Nov 2011 10:02:37 +0000 Subject: Fwd: Re: Suppress creation of SocksSocketImpl in SocketAdaptor's constructor In-Reply-To: <4EC80738.2000609@oracle.com> References: <4EC636F9.9020807@oracle.com> <4EC63A11.9050302@oracle.com> <4EC80738.2000609@oracle.com> Message-ID: <4ECA21BD.2070503@oracle.com> On 19/11/2011 19:44, Alan Bateman wrote: > On 18/11/2011 10:57, Chris Hegarty wrote: >> Hi Kris, >> >> I think this change should be fine, but I would like Alan to comment also. >> > I looked at it in more detail and I think it should okay. Will you > sponsor it? My only comment on the change is the catching of > SocketException causes a RuntimeException to be thrown but that is > inconsistent with other areas of this code where AssertionError or > InternalError is thrown. Yes, I can sponsor this change. And yes, I agree InternalError would be better. -Chris. > > -Alan From rednaxelafx at gmail.com Mon Nov 21 02:11:45 2011 From: rednaxelafx at gmail.com (Krystal Mok) Date: Mon, 21 Nov 2011 18:11:45 +0800 Subject: Fwd: Re: Suppress creation of SocksSocketImpl in SocketAdaptor's constructor In-Reply-To: <4ECA21BD.2070503@oracle.com> References: <4EC636F9.9020807@oracle.com> <4EC63A11.9050302@oracle.com> <4EC80738.2000609@oracle.com> <4ECA21BD.2070503@oracle.com> Message-ID: Thank you very much. I agree InternalError is better, too, even though it shouldn't be reached anyway. - Kris 2011/11/21 Chris Hegarty > On 19/11/2011 19:44, Alan Bateman wrote: > > On 18/11/2011 10:57, Chris Hegarty wrote: > >> Hi Kris, > >> > >> I think this change should be fine, but I would like Alan to comment > also. > >> > > I looked at it in more detail and I think it should okay. Will you > > sponsor it? My only comment on the change is the catching of > > SocketException causes a RuntimeException to be thrown but that is > > inconsistent with other areas of this code where AssertionError or > > InternalError is thrown. > > Yes, I can sponsor this change. And yes, I agree InternalError would be > better. > > -Chris. > > > > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20111121/45737b5c/attachment-0001.html From Alan.Bateman at oracle.com Mon Nov 21 09:35:44 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 Nov 2011 17:35:44 +0000 Subject: AsynchronousDatagramChannel implementation In-Reply-To: <000f01cca6f8$ca45bd10$5ed13730$@com> References: <000f01cca6f8$ca45bd10$5ed13730$@com> Message-ID: <4ECA8BF0.40600@oracle.com> On 19/11/2011 20:21, David Dabbs wrote: > ADC stayed in JDK7, but are the improvements in the jdk8 plan? What > was was/is deficient about the implementation? Perhaps it is something > that could be contributed. Many thanks, David AsynchronousDatagramChannel was removed from jdk7 about a year ago [1][2]. We did say we would look at it again in the future but it hasn't been a priority to date. There would be work required to clean up the spec and also re-implement (the implementation that was removed was very much a prototype). -Alan [1] http://mail.openjdk.java.net/pipermail/nio-dev/2010-October/001122.html [2] http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/5a6c63deacf3 From Alan.Bateman at oracle.com Wed Nov 23 04:26:04 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Nov 2011 12:26:04 +0000 Subject: IOException from sun.nio.fs.UnixUserPrincipals.lookupName In-Reply-To: <4ECA1ECF.4010800@linux.vnet.ibm.com> References: <4EC9FF5A.3070505@linux.vnet.ibm.com> <4ECA0D22.90702@oracle.com> <4ECA1ECF.4010800@linux.vnet.ibm.com> Message-ID: <4ECCE65C.2070401@oracle.com> On 21/11/2011 09:50, Jonathan Lu wrote: > Yes, this problem was originally found on AIX platform and I just > tested getgrnam_r(), it failed with the same errno as getpwnam_r(), so > I think if there's an adjustment, getgrnam0 should be included too. As I said, I don't see a problem extending the check to include ESRCH. It's one of these holes in the standards. Will you send the patch for both calls so that we can review it? Also is Neil going to push it or do you need me to do it? I've created a bug for it: 7115070: (fs) lookupPrincipalByName/lookupPrincipalByGroupName should treat ESRCH as not found -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20111123/bb9a321b/attachment.html From neil.richards at ngmr.net Wed Nov 23 05:46:32 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Wed, 23 Nov 2011 13:46:32 +0000 Subject: IOException from sun.nio.fs.UnixUserPrincipals.lookupName In-Reply-To: <4ECCE65C.2070401@oracle.com> References: <4EC9FF5A.3070505@linux.vnet.ibm.com> <4ECA0D22.90702@oracle.com> <4ECA1ECF.4010800@linux.vnet.ibm.com> <4ECCE65C.2070401@oracle.com> Message-ID: <1322055992.15255.51.camel@chalkhill> On Wed, 2011-11-23 at 12:26 +0000, Alan Bateman wrote: > On 21/11/2011 09:50, Jonathan Lu wrote: > > Yes, this problem was originally found on AIX platform and I just > > tested getgrnam_r(), it failed with the same errno as getpwnam_r(), > > so I think if there's an adjustment, getgrnam0 should be included > > too. > As I said, I don't see a problem extending the check to include ESRCH. > It's one of these holes in the standards. Will you send the patch for > both calls so that we can review it? Also is Neil going to push it or > do you need me to do it? I've created a bug for it: > > 7115070: (fs) lookupPrincipalByName/lookupPrincipalByGroupName should > treat ESRCH as not found > > -Alan. Hi all, I'm happy to push it once Jonathan's suggested change is agreed (once he's posted the patch). Regards, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From matthias.bergk at crossmediasolutions.de Wed Nov 23 06:53:44 2011 From: matthias.bergk at crossmediasolutions.de (Matthias Bergk) Date: Wed, 23 Nov 2011 15:53:44 +0100 Subject: DirectoryStream on Windows Message-ID: Dear all, I examined the file attributes that come with a directory stream on Windows. I found that the returned Path objects are of the class WindowsPath$WindowsPathWithAttributes. But how to get at those attributes? The following code is taken from JDK sample code: try( DirectoryStream stream = Files.newDirectoryStream(folder) ) { for( Path entry : stream ) { BasicFileAttributeView v = Files.getFileAttributeView(entry,BasicFileAttributeView.class); BasicFileAttributes a = v.readAttributes(); System.out.println( entry+" "+a.size() ); } } Unfortunately this code does not benefit from the file attributes that are available in the entries. Rather, it reads them anew from the system. Using "reflection" it is possible to get at the attributes contained in the entries: try( DirectoryStream stream = Files.newDirectoryStream(folder) ) { for( Path entry : stream ) { Field fRef = entry.getClass().getDeclaredField("ref"); if( !fRef.isAccessible() ) fRef.setAccessible(true); WeakReference ra = (WeakReference) fRef.get(entry); BasicFileAttributes a = ra.get(); System.out.println( entry+" "+a.size() ); } } This code is considerably faster if the folder is on a network and contains many files. Of course, I would prefer to read the attributes without reflection in the intended way. Best regards, Matthias Bergk Software-Entwicklung CMS - Cross Media Solutions GmbH Beethovenstra?e 5 A 97080 W?rzburg Tel: +49 (931) 385 - 369 Fax: +49 (931) 385 - 364 E-Mail: matthias.bergk at crossmediasolutions.de Internet: http://www.crossmediasolutions.de Handelsregister: W?rzburg HRB 8950 Gesch?ftsf?hrer: Michael Schardt member of Euradius -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20111123/9470a74c/attachment-0001.html From Alan.Bateman at oracle.com Wed Nov 23 07:29:56 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Nov 2011 15:29:56 +0000 Subject: DirectoryStream on Windows In-Reply-To: References: Message-ID: <4ECD1174.6050802@oracle.com> On 23/11/2011 14:53, Matthias Bergk wrote: > > Dear all, > > I examined the file attributes that come with a directory stream on > Windows. > > I found that the returned Path objects are of the class > WindowsPath$WindowsPathWithAttributes. > > But how to get at those attributes? The following code is taken from > JDK sample code: > > try( DirectoryStream stream = Files./newDirectoryStream/(folder) ) > > { > > for( Path entry : stream ) > > { > > BasicFileAttributeView v = > > Files./getFileAttributeView/(entry,BasicFileAttributeView.class); > > BasicFileAttributes a = v.readAttributes(); > > System./out/.println( entry+" "+a.size() ); > > } > > } > > Unfortunately this code does not benefit from the file attributes that > are available in the entries. > > Rather, it reads them anew from the system. > > Using "reflection" it is possible to get at the attributes contained > in the entries: > > try( DirectoryStream stream = Files./newDirectoryStream/(folder) ) > > { > > for( Path entry : stream ) > > { > > Field fRef = entry.getClass().getDeclaredField("ref"); > > if( !fRef.isAccessible() ) > > fRef.setAccessible(true); > > WeakReference ra = > > (WeakReference) fRef.get(entry); > > BasicFileAttributes a = ra.get(); > > System./out/.println( entry+" "+a.size() ); > > } > > } > > This code is considerably faster if the folder is on a network and > contains many files. > > Of course, I would prefer to read the attributes without reflection in > the intended way. > > The first example is the recommended way to do this but would be nicer if we did: BasicFileAttributes attrs = Files.readAttributes(entry, BasicFileAttributes.class); On the caching then the JDK can't know in advance that you will will invoke readAttributes on each file in the directory. The only place in the API where it is known is Files.walkFileTree so you should fine that will give you the performance you are looking for. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20111123/e7455aec/attachment-0001.html From neil.richards at ngmr.net Thu Nov 24 04:19:46 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Thu, 24 Nov 2011 12:19:46 +0000 Subject: IOException from sun.nio.fs.UnixUserPrincipals.lookupName In-Reply-To: <1322055992.15255.51.camel@chalkhill> References: <4EC9FF5A.3070505@linux.vnet.ibm.com> <4ECA0D22.90702@oracle.com> <4ECA1ECF.4010800@linux.vnet.ibm.com> <4ECCE65C.2070401@oracle.com> <1322055992.15255.51.camel@chalkhill> Message-ID: <1322137186.31325.67.camel@chalkhill> On Wed, 2011-11-23 at 13:46 +0000, Neil Richards wrote: > On Wed, 2011-11-23 at 12:26 +0000, Alan Bateman wrote: > > On 21/11/2011 09:50, Jonathan Lu wrote: > > > Yes, this problem was originally found on AIX platform and I just > > > tested getgrnam_r(), it failed with the same errno as getpwnam_r(), > > > so I think if there's an adjustment, getgrnam0 should be included > > > too. > > As I said, I don't see a problem extending the check to include ESRCH. > > It's one of these holes in the standards. Will you send the patch for > > both calls so that we can review it? Also is Neil going to push it or > > do you need me to do it? I've created a bug for it: > > > > 7115070: (fs) lookupPrincipalByName/lookupPrincipalByGroupName should > > treat ESRCH as not found > > > > -Alan. > > Hi all, > I'm happy to push it once Jonathan's suggested change is agreed (once > he's posted the patch). > > Regards, Neil > Jonathan's having some fun getting to his mail server this morning, so has slipped his suggested change into my digital hands (by other means). So, on his behalf, please find his change below in 'hg export' form. I've also posted this as a webrev, for ease of review [1]. Regards, Neil [1] http://cr.openjdk.java.net/~ngmr/7115070/webrev.00/ -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU # HG changeset patch # User ngmr # Date 1322134471 0 # Node ID 4a69082ac5d9a7dc0ca66282ec79e0df76c9fdb8 # Parent 99632935785e2038b2fc836da9f2ede69dea294b 7115070: (fs) lookupPrincipalByName/lookupPrincipalByGroupName should treat ESRCH as not found Reviewed-by: alanb Contributed-by: Jonathan Lu diff --git a/src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c b/src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c --- a/src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c +++ b/src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c @@ -996,7 +996,7 @@ if (res != 0 || p == NULL || p->pw_name == NULL || *(p->pw_name) == '\0') { /* not found or error */ - if (errno != 0 && errno != ENOENT) + if (errno != 0 && errno != ENOENT && errno != ESRCH) throwUnixException(env, errno); } else { uid = p->pw_uid; @@ -1042,7 +1042,7 @@ retry = 0; if (res != 0 || g == NULL || g->gr_name == NULL || *(g->gr_name) == '\0') { /* not found or error */ - if (errno != 0 && errno != ENOENT) { + if (errno != 0 && errno != ENOENT && errno != ESRCH) { if (errno == ERANGE) { /* insufficient buffer size so need larger buffer */ buflen += ENT_BUF_SIZE; From Alan.Bateman at oracle.com Thu Nov 24 05:03:51 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 Nov 2011 13:03:51 +0000 Subject: IOException from sun.nio.fs.UnixUserPrincipals.lookupName In-Reply-To: <1322137186.31325.67.camel@chalkhill> References: <4EC9FF5A.3070505@linux.vnet.ibm.com> <4ECA0D22.90702@oracle.com> <4ECA1ECF.4010800@linux.vnet.ibm.com> <4ECCE65C.2070401@oracle.com> <1322055992.15255.51.camel@chalkhill> <1322137186.31325.67.camel@chalkhill> Message-ID: <4ECE40B7.6050905@oracle.com> On 24/11/2011 12:19, Neil Richards wrote: > : > Jonathan's having some fun getting to his mail server this morning, so > has slipped his suggested change into my digital hands (by other means). > > So, on his behalf, please find his change below in 'hg export' form. > > I've also posted this as a webrev, for ease of review [1]. > > Regards, Neil > > [1] http://cr.openjdk.java.net/~ngmr/7115070/webrev.00/ This looks fine to me. -Alan. From chris.hegarty at oracle.com Fri Nov 25 03:38:33 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 25 Nov 2011 11:38:33 +0000 Subject: Fwd: Re: Suppress creation of SocksSocketImpl in SocketAdaptor's constructor In-Reply-To: References: <4EC636F9.9020807@oracle.com> <4EC63A11.9050302@oracle.com> <4EC80738.2000609@oracle.com> <4ECA21BD.2070503@oracle.com> Message-ID: <4ECF7E39.4060501@oracle.com> For clarity, the changes I intend to push for this are as follows: diff -r 2db942c7eb9c src/share/classes/sun/nio/ch/SocketAdaptor.java --- a/src/share/classes/sun/nio/ch/SocketAdaptor.java Mon Nov 21 12:57:36 2011 +0000 +++ b/src/share/classes/sun/nio/ch/SocketAdaptor.java Fri Nov 25 11:33:47 2011 +0000 @@ -57,13 +57,17 @@ public class SocketAdaptor // Timeout "option" value for reads private volatile int timeout = 0; - // ## super will create a useless impl - private SocketAdaptor(SocketChannelImpl sc) { + private SocketAdaptor(SocketChannelImpl sc) throws SocketException { + super((SocketImpl) null); this.sc = sc; } public static Socket create(SocketChannelImpl sc) { - return new SocketAdaptor(sc); + try { + return new SocketAdaptor(sc); + } catch (SocketException e) { + throw new InternalError("should not reach here"); + } } public SocketChannel getChannel() { Thanks, -Chris. On 21/11/2011 10:11, Krystal Mok wrote: > Thank you very much. I agree InternalError is better, too, even though > it shouldn't be reached anyway. > > - Kris > > 2011/11/21 Chris Hegarty > > > On 19/11/2011 19:44, Alan Bateman wrote: > > On 18/11/2011 10:57, Chris Hegarty wrote: > >> Hi Kris, > >> > >> I think this change should be fine, but I would like Alan to > comment also. > >> > > I looked at it in more detail and I think it should okay. Will you > > sponsor it? My only comment on the change is the catching of > > SocketException causes a RuntimeException to be thrown but that is > > inconsistent with other areas of this code where AssertionError or > > InternalError is thrown. > > Yes, I can sponsor this change. And yes, I agree InternalError would be > better. > > -Chris. > > > > > -Alan > > From sajia at taobao.com Fri Nov 25 03:43:25 2011 From: sajia at taobao.com (=?gb2312?B?yPblyA==?=) Date: Fri, 25 Nov 2011 19:43:25 +0800 Subject: Fwd: Re: Suppress creation of SocksSocketImpl in SocketAdaptor's constructor In-Reply-To: <4ECF7E39.4060501@oracle.com> References: <4EC636F9.9020807@oracle.com> <4EC63A11.9050302@oracle.com> <4EC80738.2000609@oracle.com> <4ECA21BD.2070503@oracle.com> <4ECF7E39.4060501@oracle.com> Message-ID: Looks good to me. Thank you Chris :-) - Kris (This is Krystal Mok's work email) From: nio-dev-bounces at openjdk.java.net [mailto:nio-dev-bounces at openjdk.java.net] on behalf of Chris Hegarty Date: Nov 25, 2011 19:39 To: Krystal Mok CC: nio-dev Title: Re: Fwd: Re: Suppress creation of SocksSocketImpl in SocketAdaptor's constructor For clarity, the changes I intend to push for this are as follows: diff -r 2db942c7eb9c src/share/classes/sun/nio/ch/SocketAdaptor.java --- a/src/share/classes/sun/nio/ch/SocketAdaptor.java Mon Nov 21 12:57:36 2011 +0000 +++ b/src/share/classes/sun/nio/ch/SocketAdaptor.java Fri Nov 25 11:33:47 2011 +0000 @@ -57,13 +57,17 @@ public class SocketAdaptor // Timeout "option" value for reads private volatile int timeout = 0; - // ## super will create a useless impl - private SocketAdaptor(SocketChannelImpl sc) { + private SocketAdaptor(SocketChannelImpl sc) throws SocketException { + super((SocketImpl) null); this.sc = sc; } public static Socket create(SocketChannelImpl sc) { - return new SocketAdaptor(sc); + try { + return new SocketAdaptor(sc); + } catch (SocketException e) { + throw new InternalError("should not reach here"); + } } public SocketChannel getChannel() { Thanks, -Chris. On 21/11/2011 10:11, Krystal Mok wrote: > Thank you very much. I agree InternalError is better, too, even though > it shouldn't be reached anyway. > > - Kris > > 2011/11/21 Chris Hegarty > > > On 19/11/2011 19:44, Alan Bateman wrote: > > On 18/11/2011 10:57, Chris Hegarty wrote: > >> Hi Kris, > >> > >> I think this change should be fine, but I would like Alan to > comment also. > >> > > I looked at it in more detail and I think it should okay. Will you > > sponsor it? My only comment on the change is the catching of > > SocketException causes a RuntimeException to be thrown but that is > > inconsistent with other areas of this code where AssertionError or > > InternalError is thrown. > > Yes, I can sponsor this change. And yes, I agree InternalError would be > better. > > -Chris. > > > > > -Alan > > This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. ??????(????????????)???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? From Alan.Bateman at oracle.com Fri Nov 25 05:37:59 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 Nov 2011 13:37:59 +0000 Subject: Fwd: Re: Suppress creation of SocksSocketImpl in SocketAdaptor's constructor In-Reply-To: <4ECF7E39.4060501@oracle.com> References: <4EC636F9.9020807@oracle.com> <4EC63A11.9050302@oracle.com> <4EC80738.2000609@oracle.com> <4ECA21BD.2070503@oracle.com> <4ECF7E39.4060501@oracle.com> Message-ID: <4ECF9A37.40205@oracle.com> On 25/11/2011 11:38, Chris Hegarty wrote: > For clarity, the changes I intend to push for this are as follows: Looks fine to me, thanks for taking it. I probably would make it "Should" rather than "should" just to be consistent with the other internal errors in this area but it's not a big deal as it should never happen. -Alan. From Alan.Bateman at oracle.com Sun Nov 27 10:09:09 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 27 Nov 2011 18:09:09 +0000 Subject: Hardcoded default providers for asynchronous channel and file system In-Reply-To: <4ECA0AA8.7060308@linux.vnet.ibm.com> References: <4EB3A1A5.6020705@linux.vnet.ibm.com> <4EB6CEE5.30108@oracle.com> <4EB8F24C.903@linux.vnet.ibm.com> <4EBBE0A1.7070801@oracle.com> <4EBCE14D.2090305@linux.vnet.ibm.com> <4EC16787.7090100@oracle.com> <4EC390E7.3060608@linux.vnet.ibm.com> <4ECA0AA8.7060308@linux.vnet.ibm.com> Message-ID: <4ED27CC5.6070408@oracle.com> On 21/11/2011 08:24, Jonathan Lu wrote: > Hello Alan, nio-dev, > > Any comments on this patch? I'm not sure about this yet as the real issue here is that we've got code for more than one platform in the directory tree. I've started a thread on build-dev on this topic [1], and with the build infra project [2] then it may be better we held back changes to the build until that it further along and (hopefully) in jdk8. -Alan. [1] http://mail.openjdk.java.net/pipermail/build-dev/2011-November/005225.html [2] http://openjdk.java.net/projects/build-infra/ From neil.richards at ngmr.net Mon Nov 28 09:04:44 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Mon, 28 Nov 2011 17:04:44 +0000 Subject: IOException from sun.nio.fs.UnixUserPrincipals.lookupName In-Reply-To: <4ECE40B7.6050905@oracle.com> References: <4EC9FF5A.3070505@linux.vnet.ibm.com> <4ECA0D22.90702@oracle.com> <4ECA1ECF.4010800@linux.vnet.ibm.com> <4ECCE65C.2070401@oracle.com> <1322055992.15255.51.camel@chalkhill> <1322137186.31325.67.camel@chalkhill> <4ECE40B7.6050905@oracle.com> Message-ID: <1322499884.6281.2.camel@chalkhill> On Thu, 2011-11-24 at 13:03 +0000, Alan Bateman wrote: > On 24/11/2011 12:19, Neil Richards wrote: > > : > > Jonathan's having some fun getting to his mail server this morning, so > > has slipped his suggested change into my digital hands (by other means). > > > > So, on his behalf, please find his change below in 'hg export' form. > > > > I've also posted this as a webrev, for ease of review [1]. > > > > Regards, Neil > > > > [1] http://cr.openjdk.java.net/~ngmr/7115070/webrev.00/ > This looks fine to me. > > -Alan. > Thanks, Alan. I've now pushed the change [1]. Regards, Neil [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/955aae8c1106 -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU