From lvjing at linux.vnet.ibm.com Tue Mar 1 02:21:33 2011 From: lvjing at linux.vnet.ibm.com (Jing LV) Date: Tue, 01 Mar 2011 18:21:33 +0800 Subject: deadlock in NIO component (known bug: Oracle 6429204) Message-ID: <4D6CC8AD.90306@linux.vnet.ibm.com> Hello, I've found a bug, and find it already reported (see Oracle Bug 6429204 Concurrent Selector.register and SelectionKey.interestOps can ignore interestOps). However I see there is no work is going on currectly. So does someone already has a fix? If no,I suppse I may provide a patch, will someone help me on that? -- Best Regards, Jimmy, Jing LV -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110301/2ba4c971/attachment.html From Alan.Bateman at oracle.com Tue Mar 1 02:06:55 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 01 Mar 2011 10:06:55 +0000 Subject: 7023034: Files.createTempDirectory((Path)null, "temp") does not throw NPE Message-ID: <4D6CC53F.9000306@oracle.com> A small oversight in the implementation of Files.createTempFile and createTempDirectory. If the temporary directory is specified as null then NPE should be thrown. The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/7023034/webrev/ Thanks, Alan. From Alan.Bateman at oracle.com Tue Mar 1 02:42:09 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 01 Mar 2011 10:42:09 +0000 Subject: deadlock in NIO component (known bug: Oracle 6429204) In-Reply-To: <4D6CC8AD.90306@linux.vnet.ibm.com> References: <4D6CC8AD.90306@linux.vnet.ibm.com> Message-ID: <4D6CCD81.5010308@oracle.com> Jing LV wrote: > Hello, > > I've found a bug, and find it already reported (see Oracle Bug > 6429204 Concurrent Selector.register and SelectionKey.interestOps can > ignore interestOps). > However I see there is no work is going on currectly. So does > someone already has a fix? If no,I suppse I may provide a patch, will > someone help me on that? > -- > Best Regards, > Jimmy, Jing LV It would be great if you can provide a test case that demonstrates the issue, and say which platforms you've observed it on (just to make sure that we're talking about the same issue in that bug). -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110301/b2918d12/attachment.html From forax at univ-mlv.fr Tue Mar 1 03:06:41 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 01 Mar 2011 12:06:41 +0100 Subject: 7023034: Files.createTempDirectory((Path)null, "temp") does not throw NPE In-Reply-To: <4D6CC53F.9000306@oracle.com> References: <4D6CC53F.9000306@oracle.com> Message-ID: <4D6CD341.3000404@univ-mlv.fr> Le 01/03/2011 11:06, Alan Bateman a ?crit : > > A small oversight in the implementation of Files.createTempFile and > createTempDirectory. If the temporary directory is specified as null > then NPE should be thrown. The webrev with the changes is here: > http://cr.openjdk.java.net/~alanb/7023034/webrev/ > > Thanks, > Alan. Hi Alan, In the test, you test twice the same thing. Files.createTempFile("blah", ".tmp", (FileAttribute)null); should be: Files.createTempFile("blah", ".tmp", (FileAttribute[])null); otherwise it's Ok. R?mi From Alan.Bateman at oracle.com Tue Mar 1 03:14:51 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 01 Mar 2011 11:14:51 +0000 Subject: 7023034: Files.createTempDirectory((Path)null, "temp") does not throw NPE In-Reply-To: <4D6CD341.3000404@univ-mlv.fr> References: <4D6CC53F.9000306@oracle.com> <4D6CD341.3000404@univ-mlv.fr> Message-ID: <4D6CD52B.1080903@oracle.com> R?mi Forax wrote: > : > Hi Alan, > In the test, you test twice the same thing. > > Files.createTempFile("blah", ".tmp", (FileAttribute)null); > > should be: > > Files.createTempFile("blah", ".tmp", (FileAttribute[])null); > > otherwise it's Ok. > > R?mi > Well spotted, thank you! I'll fix this before pushing the change. -Alan From Alan.Bateman at oracle.com Tue Mar 1 14:02:37 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 01 Mar 2011 22:02:37 +0000 Subject: 6944810: (ch) Assert failure in sun.nio.ch.PendingIoCache.clearPendingIoMap [win] Message-ID: <4D6D6CFD.3030802@oracle.com> In the asynchronous I/O tests include tests that exercise asynchronous close. These have failed a couple of times on Windows. It turns out that two of the operations, AsynchronousFileChannel.read and AsynchronousSocketChannel.connect have a timing bug in that they return the OVERLAPPED structure to the per-channel cache after releasing the channel's read lock (these channels use ReadWriteLocks). This creates a bug with asynchronous close where it has to synthesize failure for I/O operations that don't abort in a timely manner. That code in turn has a bug where it was silently consuming the interrupt status. The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/6944810/webrev/ Note that I haven't added a new test as part of this (I can add the bugID to the existing tests). I've also removed the tests from the ProblemList file. The webrev also includes fixes to typos in AsynchronousFileChannel that Wolfgang Baltes mailed me off-list about. -Alan. From chris.hegarty at oracle.com Thu Mar 3 06:44:20 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 03 Mar 2011 14:44:20 +0000 Subject: 6944810: (ch) Assert failure in sun.nio.ch.PendingIoCache.clearPendingIoMap [win] In-Reply-To: <4D6D6CFD.3030802@oracle.com> References: <4D6D6CFD.3030802@oracle.com> Message-ID: <4D6FA944.8090105@oracle.com> Looks ok to me. -Chris. On 01/03/2011 22:02, Alan Bateman wrote: > > In the asynchronous I/O tests include tests that exercise asynchronous > close. These have failed a couple of times on Windows. It turns out that > two of the operations, AsynchronousFileChannel.read and > AsynchronousSocketChannel.connect have a timing bug in that they return > the OVERLAPPED structure to the per-channel cache after releasing the > channel's read lock (these channels use ReadWriteLocks). This creates a > bug with asynchronous close where it has to synthesize failure for I/O > operations that don't abort in a timely manner. That code in turn has a > bug where it was silently consuming the interrupt status. The webrev > with the changes is here: > http://cr.openjdk.java.net/~alanb/6944810/webrev/ > Note that I haven't added a new test as part of this (I can add the > bugID to the existing tests). I've also removed the tests from the > ProblemList file. > > The webrev also includes fixes to typos in AsynchronousFileChannel that > Wolfgang Baltes mailed me off-list about. > > -Alan. From Alan.Bateman at oracle.com Fri Mar 4 10:03:35 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 04 Mar 2011 18:03:35 +0000 Subject: 7023403: (ch) sun.nio.ch.SolarisEventPort.startPoll failed with AssertionError Message-ID: <4D712977.9030603@oracle.com> This is another small fix to the asynchronous I/O implementation. One the tests (test/java/nio/channels/AsynchronousSocketChannel/Basic.java) has failed a couple of times on solaris-x64. It's not easy to reproduce but basically if a channel is asynchronously closed at just around the time that it becomes writable and if the channel also has an outstanding read then it will restart the read with an invalid file descriptor. Same thing if asynchronously closed at just around the time that it becomes readable with an outstanding write operations. The fix is small and ensues that it doesn't restart the read (or write) then closed. The webrev with the changes is here; http://cr.openjdk.java.net/~alanb/7023403/webrev/ Thanks, -Alan. From forax at univ-mlv.fr Fri Mar 4 10:51:45 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 04 Mar 2011 19:51:45 +0100 Subject: 7023403: (ch) sun.nio.ch.SolarisEventPort.startPoll failed with AssertionError In-Reply-To: <4D712977.9030603@oracle.com> References: <4D712977.9030603@oracle.com> Message-ID: <4D7134C1.2030408@univ-mlv.fr> On 03/04/2011 07:03 PM, Alan Bateman wrote: > > This is another small fix to the asynchronous I/O implementation. One > the tests > (test/java/nio/channels/AsynchronousSocketChannel/Basic.java) has > failed a couple of times on solaris-x64. It's not easy to reproduce > but basically if a channel is asynchronously closed at just around the > time that it becomes writable and if the channel also has an > outstanding read then it will restart the read with an invalid file > descriptor. Same thing if asynchronously closed at just around the > time that it becomes readable with an outstanding write operations. > The fix is small and ensues that it doesn't restart the read (or > write) then closed. The webrev with the changes is here; > http://cr.openjdk.java.net/~alanb/7023403/webrev/ > > Thanks, > -Alan. > In my opinion, it's more readable to do an instanceof AsynchronousCloseException. Even if AsynchronousCloseException inherits from ClosedChannelException. Also, it can be more efficient to do the instanceof check in lockAndUpdateEvents; R?mi From Alan.Bateman at oracle.com Fri Mar 4 11:32:34 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 04 Mar 2011 19:32:34 +0000 Subject: 7023403: (ch) sun.nio.ch.SolarisEventPort.startPoll failed with AssertionError In-Reply-To: <4D7134C1.2030408@univ-mlv.fr> References: <4D712977.9030603@oracle.com> <4D7134C1.2030408@univ-mlv.fr> Message-ID: <4D713E52.1090904@oracle.com> R?mi Forax wrote: > > In my opinion, it's more readable to do an instanceof > AsynchronousCloseException. > Even if AsynchronousCloseException inherits from ClosedChannelException. Okay, either will work here. > > Also, it can be more efficient to do the instanceof check in > lockAndUpdateEvents; That would mean that lockAndUpdateEvents would need to know about the exception, whereas I think it's a bit more understandable now. -Alan From forax at univ-mlv.fr Fri Mar 4 11:43:43 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 04 Mar 2011 20:43:43 +0100 Subject: 7023403: (ch) sun.nio.ch.SolarisEventPort.startPoll failed with AssertionError In-Reply-To: <4D713E52.1090904@oracle.com> References: <4D712977.9030603@oracle.com> <4D7134C1.2030408@univ-mlv.fr> <4D713E52.1090904@oracle.com> Message-ID: <4D7140EF.6090102@univ-mlv.fr> On 03/04/2011 08:32 PM, Alan Bateman wrote: > R?mi Forax wrote: >> >> In my opinion, it's more readable to do an instanceof >> AsynchronousCloseException. >> Even if AsynchronousCloseException inherits from ClosedChannelException. > Okay, either will work here. > >> >> Also, it can be more efficient to do the instanceof check in >> lockAndUpdateEvents; > That would mean that lockAndUpdateEvents would need to know about the > exception, whereas I think it's a bit more understandable now. I agree. > > -Alan so looks good to me. R?mi From lvjing at linux.vnet.ibm.com Mon Mar 7 03:41:05 2011 From: lvjing at linux.vnet.ibm.com (Jing LV) Date: Mon, 07 Mar 2011 19:41:05 +0800 Subject: deadlock in NIO component (known bug: Oracle 6429204) In-Reply-To: <4D6CCD81.5010308@oracle.com> References: <4D6CC8AD.90306@linux.vnet.ibm.com> <4D6CCD81.5010308@oracle.com> Message-ID: <4D74C451.6010502@linux.vnet.ibm.com> ? 2011-3-1 18:42, Alan Bateman ??: > Jing LV wrote: >> Hello, >> >> I've found a bug, and find it already reported (see Oracle Bug >> 6429204 Concurrent Selector.register and SelectionKey.interestOps can >> ignore interestOps). >> However I see there is no work is going on currectly. So does >> someone already has a fix? If no,I suppse I may provide a patch, will >> someone help me on that? >> -- >> Best Regards, >> Jimmy, Jing LV > It would be great if you can provide a test case that demonstrates the > issue, and say which platforms you've observed it on (just to make > sure that we're talking about the same issue in that bug). > > -Alan Hi Alan, Sorry for late replay. Here is the testcase I got. I see deadlock running the testcase: public class Deadlock { public static void main(String[] args) throws Exception { final Selector selector = Selector.open(); Thread thread = new Thread(new Runnable() { public void run() { while (true) { try { System.out.println("select"); selector.select(100); } catch (Exception e) { } } } }); thread.start(); while (true) { SocketChannel channel = SocketChannel.open(); channel.configureBlocking(false); channel.register(selector, 0, null); System.out.println("close"); channel.close(); } } } The solution may be add a new lock for cancel(). -- Best Regards, Jimmy, Jing LV -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110307/d0c59f2c/attachment.html From Alan.Bateman at oracle.com Mon Mar 7 04:28:34 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 07 Mar 2011 12:28:34 +0000 Subject: deadlock in NIO component (known bug: Oracle 6429204) In-Reply-To: <4D74C451.6010502@linux.vnet.ibm.com> References: <4D6CC8AD.90306@linux.vnet.ibm.com> <4D6CCD81.5010308@oracle.com> <4D74C451.6010502@linux.vnet.ibm.com> Message-ID: <4D74CF72.3040309@oracle.com> Jing LV wrote: > ? 2011-3-1 18:42, Alan Bateman ??: > > Sorry for late replay. Here is the testcase I got. I see deadlock > running the testcase: Thanks for creating a test. So which operating system does this duplicate on for you? Also when you say "deadlock", is the deadlock reported in the thread dump? If so, can you also send the thread dump. Thanks, -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110307/0f5851a0/attachment.html From Alan.Bateman at oracle.com Mon Mar 14 06:35:26 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Mar 2011 13:35:26 +0000 Subject: 7026376: (dc) DatagramChannel created without specifying protocol family fails to join IPv4 group Message-ID: <4D7E199E.1040902@oracle.com> This is a small fix to the mulitcast support in DatagramChannel. If someone creates a DatagramChannel without specifying the protocol family then they get a DatagramChannel to an IPv6 socket if IPv6 is enabled. If they then attempt to join an IPv4 multicast group then it may succeed or may fail (the spec is clear that there is no guarantee that a channel to a socket in one protocol family can join a multicast group with an address that corresponds to another protocol family). When not supported then the exception today is not clear. The change here ensures that IllegalArgumentException is thrown with a clear message detail when not supported and for Linux, changes the implementation to use Net.join4 rather than Net.join6 for this case. The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/7026376/webrev/ Thanks, Alan From Alan.Bateman at oracle.com Mon Mar 14 07:36:06 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Mar 2011 14:36:06 +0000 Subject: 7017446: (fs) Updates to file system API (3/2011) Message-ID: <4D7E27D6.6050703@oracle.com> This webrev contains a couple of small API updates: 1. Files.getAttribute and readAttributes currently return null (or an empty map) when invoked with invalid attribute names. The proposed change here fixes this so that IllegalArgumentException is thrown when invalid names are used. UOE will continue to be throw if an unsupported view is specified. 2. A method is added to WatchKey to return the the object for which the watch key was created. This has come up several times, and the implementation changes for this were actually included in the last round of updates. For now the methods the Watchable and so must be cast to the specific type when used. Not ideal but the alternative propagates a type parameter and would require restricting the WatchService so that it only watches objects of one type. 3. The Files.createTempFile and createTemptDirectory methods that specify the temporary file directory are restricted to the default file system. The rational for this is that it may not be possible to generate a file name suitable for use with a custom file system. In the future we can extend the provider interface to support this if needed. 4. A couple of questions/inconsistencies were observed with the zip provider when comparing paths in different zip file systems. To address this, Path.equals is changed so that it returns false if the given object is a Path associated with a different FileSystem (used to return false if associated with a different provider). The startsWith/endsWith methods also return false if the given path is associated with a different FileSystem. This also addressed another concern that came up no this mailing list some time ago where ProviderMismatchException is thrown. The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/7017446/webrev/ Thanks, Alan From wolfgang.baltes at laposte.net Mon Mar 14 10:44:36 2011 From: wolfgang.baltes at laposte.net (Wolfgang Baltes) Date: Mon, 14 Mar 2011 10:44:36 -0700 Subject: 7017446: (fs) Updates to file system API (3/2011) In-Reply-To: <4D7E27D6.6050703@oracle.com> References: <4D7E27D6.6050703@oracle.com> Message-ID: <4D7E5404.8050108@laposte.net> On 2011-03-14 07:36, Alan Bateman wrote: > > > This webrev contains a couple of small API updates: > > 1. Files.getAttribute and readAttributes currently return null (or an > empty map) when invoked with invalid attribute names. The proposed > change here fixes this so that IllegalArgumentException is thrown when > invalid names are used. UOE will continue to be throw if an > unsupported view is specified. > > 2. A method is added to WatchKey to return the the object for which > the watch key was created. This has come up several times, and the > implementation changes for this were actually included in the last > round of updates. For now the methods the Watchable and so must be > cast to the specific type when used. Not ideal but the alternative > propagates a type parameter and would require restricting the > WatchService so that it only watches objects of one type. > > 3. The Files.createTempFile and createTemptDirectory methods that > specify the temporary file directory are restricted to the default > file system. The rational for this is that it may not be possible to > generate a file name suitable for use with a custom file system. In > the future we can extend the provider interface to support this if > needed. > > 4. A couple of questions/inconsistencies were observed with the zip > provider when comparing paths in different zip file systems. To > address this, Path.equals is changed so that it returns false if the > given object is a Path associated with a different FileSystem (used to > return false if associated with a different provider). The > startsWith/endsWith methods also return false if the given path is > associated with a different FileSystem. This also addressed another > concern that came up no this mailing list some time ago where > ProviderMismatchException is thrown. > > The webrev with the changes is here: > http://cr.openjdk.java.net/~alanb/7017446/webrev/ > > Thanks, > Alan Thanks, Alan, for implementing the change to WatchKey. Of the possible trade-offs regarding the return type, the one you made is probably the easiest to work with. I also support the other API changes and had a look at the code changes which all look ok to me. Wolfgang. From xueming.shen at oracle.com Mon Mar 14 23:13:54 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 14 Mar 2011 23:13:54 -0700 Subject: 7017446: (fs) Updates to file system API (3/2011) In-Reply-To: <4D7E27D6.6050703@oracle.com> References: <4D7E27D6.6050703@oracle.com> Message-ID: <4D7F03A2.4070306@oracle.com> On 3/14/2011 7:36 AM, Alan Bateman wrote: > > This webrev contains a couple of small API updates: > > 1. Files.getAttribute and readAttributes currently return null (or an > empty map) when invoked with invalid attribute names. The proposed > change here fixes this so that IllegalArgumentException is thrown when > invalid names are used. UOE will continue to be throw if an > unsupported view is specified. > > 2. A method is added to WatchKey to return the the object for which > the watch key was created. This has come up several times, and the > implementation changes for this were actually included in the last > round of updates. For now the methods the Watchable and so must be > cast to the specific type when used. Not ideal but the alternative > propagates a type parameter and would require restricting the > WatchService so that it only watches objects of one type. > > 3. The Files.createTempFile and createTemptDirectory methods that > specify the temporary file directory are restricted to the default > file system. The rational for this is that it may not be possible to > generate a file name suitable for use with a custom file system. In > the future we can extend the provider interface to support this if > needed. > > 4. A couple of questions/inconsistencies were observed with the zip > provider when comparing paths in different zip file systems. To > address this, Path.equals is changed so that it returns false if the > given object is a Path associated with a different FileSystem (used to > return false if associated with a different provider). The > startsWith/endsWith methods also return false if the given path is > associated with a different FileSystem. This also addressed another > concern that came up no this mailing list some time ago where > ProviderMismatchException is thrown. > > The webrev with the changes is here: > http://cr.openjdk.java.net/~alanb/7017446/webrev/ > > Thanks, > Alan Changes look fine. Minor comments (1) sun.nio.fs.Util.java #65/76 diamond conversion (2) newHashSet might not be necessary in all existing use cases, simply do unicode(Set set, E...e) { ...} it does not save you lots though:-) -Sherman From chris.hegarty at oracle.com Tue Mar 15 02:28:29 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 15 Mar 2011 09:28:29 +0000 Subject: 7026376: (dc) DatagramChannel created without specifying protocol family fails to join IPv4 group Message-ID: <4D7F313D.9060404@oracle.com> > This is a small fix to the mulitcast support in DatagramChannel. If > someone creates a DatagramChannel without specifying the protocol > family then they get a DatagramChannel to an IPv6 socket if IPv6 is > enabled. If they then attempt to join an IPv4 multicast group then it > may succeed or may fail (the spec is clear that there is no guarantee > that a channel to a socket in one protocol family can join a > multicast group with an address that corresponds to another protocol > family). When not supported then the exception today is not clear. > The change here ensures that IllegalArgumentException is thrown with > a clear message detail when not supported and for Linux, changes the > implementation to use Net.join4 rather than Net.join6 for this case. > The webrev with the changes is here: > http://cr.openjdk.java.net/~alanb/7026376/webrev/ I'm fine with this change as is, but here are a few minor comments: In DatagramChannelImpl.innerJoin() the else { throw new IllegalArgumentException("Address type not supported"); } seems unnecessary, but maybe ok if we expect support for new protocol families to be added DatagramChannelImpl. I guess canJoin6WithIPv4Group and canIPv6SocketJoinIPv4Group don't have to be implemented as native methods, but they look fine. -Chris. > > Thanks, > Alan From Alan.Bateman at oracle.com Tue Mar 15 02:41:05 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Mar 2011 09:41:05 +0000 Subject: 7026376: (dc) DatagramChannel created without specifying protocol family fails to join IPv4 group In-Reply-To: <4D7F313D.9060404@oracle.com> References: <4D7F313D.9060404@oracle.com> Message-ID: <4D7F3431.4030902@oracle.com> Chris Hegarty wrote: > : > > I'm fine with this change as is, but here are a few minor comments: > > In DatagramChannelImpl.innerJoin() the > else { throw new IllegalArgumentException("Address type not > supported"); } > seems unnecessary, but maybe ok if we expect support for new protocol > families to be added DatagramChannelImpl. You're right, this is really a "should not reach here" path and should be an AssertionError. I'll fix that. > > I guess canJoin6WithIPv4Group and canIPv6SocketJoinIPv4Group don't > have to be implemented as native methods, but they look fine. I toyed with an additional class to encapsulate the platform capabilities but it would require a class per platform and hardly seems worth it for this. -Alan From Alan.Bateman at oracle.com Tue Mar 15 02:44:52 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Mar 2011 09:44:52 +0000 Subject: 7017446: (fs) Updates to file system API (3/2011) In-Reply-To: <4D7E5404.8050108@laposte.net> References: <4D7E27D6.6050703@oracle.com> <4D7E5404.8050108@laposte.net> Message-ID: <4D7F3514.80809@oracle.com> Wolfgang Baltes wrote: > Thanks, Alan, for implementing the change to WatchKey. Of the possible > trade-offs regarding the return type, the one you made is probably the > easiest to work with. Thanks Wolfgang. Yes, I think this is the simplest for now as alternatives cause the type parameter to ripple through to everything else and turn out not to be very satisfactory. -Alan From Alan.Bateman at oracle.com Fri Mar 18 04:16:04 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 18 Mar 2011 11:16:04 +0000 Subject: 7028468: (fs) FileSystems.getDefault() fails when kernel micro version contains/ends non-numeric characters Message-ID: <4D833EF4.9060500@oracle.com> Someone trying out jdk7 on a Linux kernel reporting itself as "2.6.38lab" exposed a bug in the version parsing code. Easy to fix, but looking at it now, the only reason this code looks the version is to know whether the inotify based WatchService can be returned by the newWatchService method. My guess is that it should be rare for folks still running distributions with kernels older than 2.6.13 (kernel was released March 2006). If folks agree then the simplest solution is just to remove the version check: http://cr.openjdk.java.net/~alanb/7028468/webrev/ Thanks, Alan. From forax at univ-mlv.fr Fri Mar 18 05:53:23 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 18 Mar 2011 13:53:23 +0100 Subject: 7028468: (fs) FileSystems.getDefault() fails when kernel micro version contains/ends non-numeric characters In-Reply-To: <4D833EF4.9060500@oracle.com> References: <4D833EF4.9060500@oracle.com> Message-ID: <4D8355C3.4070500@univ-mlv.fr> On 03/18/2011 12:16 PM, Alan Bateman wrote: > > Someone trying out jdk7 on a Linux kernel reporting itself as > "2.6.38lab" exposed a bug in the version parsing code. Easy to fix, > but looking at it now, the only reason this code looks the version is > to know whether the inotify based WatchService can be returned by the > newWatchService method. My guess is that it should be rare for folks > still running distributions with kernels older than 2.6.13 (kernel was > released March 2006). If folks agree then the simplest solution is > just to remove the version check: > http://cr.openjdk.java.net/~alanb/7028468/webrev/ > > Thanks, > Alan. Looks good. cheers, R?mi From chris.hegarty at oracle.com Fri Mar 18 06:20:56 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 18 Mar 2011 13:20:56 +0000 Subject: 7028468: (fs) FileSystems.getDefault() fails when kernel micro version contains/ends non-numeric characters In-Reply-To: <4D833EF4.9060500@oracle.com> References: <4D833EF4.9060500@oracle.com> Message-ID: <4D835C38.7090202@oracle.com> I think the following imports are no longer necessary, otherwise looks fine. 31 import java.security.AccessController; 32 import sun.security.action.GetPropertyAction -Chris. On 03/18/11 11:16 AM, Alan Bateman wrote: > > Someone trying out jdk7 on a Linux kernel reporting itself as > "2.6.38lab" exposed a bug in the version parsing code. Easy to fix, but > looking at it now, the only reason this code looks the version is to > know whether the inotify based WatchService can be returned by the > newWatchService method. My guess is that it should be rare for folks > still running distributions with kernels older than 2.6.13 (kernel was > released March 2006). If folks agree then the simplest solution is just > to remove the version check: > http://cr.openjdk.java.net/~alanb/7028468/webrev/ > > Thanks, > Alan. From Alan.Bateman at oracle.com Fri Mar 18 06:26:19 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 18 Mar 2011 13:26:19 +0000 Subject: 7028468: (fs) FileSystems.getDefault() fails when kernel micro version contains/ends non-numeric characters In-Reply-To: <4D835C38.7090202@oracle.com> References: <4D833EF4.9060500@oracle.com> <4D835C38.7090202@oracle.com> Message-ID: <4D835D7B.1080307@oracle.com> Chris Hegarty wrote: > I think the following imports are no longer necessary, otherwise looks > fine. > > 31 import java.security.AccessController; > 32 import sun.security.action.GetPropertyAction > > -Chris. Thanks R?mi, thanks Chris. Yes, these imports can be removed. I'll do that before pushing. -Alan. From Alan.Bateman at oracle.com Wed Mar 23 05:37:38 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Mar 2011 12:37:38 +0000 Subject: 7029979: (fs) Path.toRealPath(boolean) should be toRealPath(LinkOption...) Message-ID: <4D89E992.2010509@oracle.com> Early versions of the file system API used a boolean parameter to indicate if symbolic links should be followed or not. These methods has long been changed to use LinkOption and the varargs syntax. There is one remaining method in the API that still uses a boolean and I'd like to get this cleaned up before the doors close on jdk7. The method is Path.toRealPath where the parameter indicates if symbolic links are resolved or not. The webrev with the proposal is here: http://cr.openjdk.java.net/~alanb/7029979/webrev/ (Sherman - I've included an updated to the zip provider as it is impacted by this change). -Alan From forax at univ-mlv.fr Wed Mar 23 06:26:10 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 23 Mar 2011 14:26:10 +0100 Subject: 7029979: (fs) Path.toRealPath(boolean) should be toRealPath(LinkOption...) In-Reply-To: <4D89E992.2010509@oracle.com> References: <4D89E992.2010509@oracle.com> Message-ID: <4D89F4F2.1070307@univ-mlv.fr> On 03/23/2011 01:37 PM, Alan Bateman wrote: > > Early versions of the file system API used a boolean parameter to > indicate if symbolic links should be followed or not. These methods > has long been changed to use LinkOption and the varargs syntax. There > is one remaining method in the API that still uses a boolean and I'd > like to get this cleaned up before the doors close on jdk7. The method > is Path.toRealPath where the parameter indicates if symbolic links are > resolved or not. The webrev with the proposal is here: > http://cr.openjdk.java.net/~alanb/7029979/webrev/ > > (Sherman - I've included an updated to the zip provider as it is > impacted by this change). > > -Alan In my opinion, you should decouple LinkOption from the type used in toRealPath to allow to specify any other options (not only link options). I propose to introduce PathResolverOption as a supertype of LinkOption with toRealPath declared toRealPath(PathResolverOption... options). R?mi From Alan.Bateman at oracle.com Wed Mar 23 07:16:35 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Mar 2011 14:16:35 +0000 Subject: 7029979: (fs) Path.toRealPath(boolean) should be toRealPath(LinkOption...) In-Reply-To: <4D89F4F2.1070307@univ-mlv.fr> References: <4D89E992.2010509@oracle.com> <4D89F4F2.1070307@univ-mlv.fr> Message-ID: <4D8A00C3.3010204@oracle.com> R?mi Forax wrote: > > In my opinion, you should decouple LinkOption from the type used in > toRealPath > to allow to specify any other options (not only link options). > I propose to introduce PathResolverOption as a supertype of LinkOption > with toRealPath declared toRealPath(PathResolverOption... options). Do you have other examples in mind? I'd prefer not introduce another type for this and I'm wondering if these other examples are really something toRealPath should be supporting or not. -Alan From forax at univ-mlv.fr Wed Mar 23 07:24:41 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 23 Mar 2011 15:24:41 +0100 Subject: 7029979: (fs) Path.toRealPath(boolean) should be toRealPath(LinkOption...) In-Reply-To: <4D8A00C3.3010204@oracle.com> References: <4D89E992.2010509@oracle.com> <4D89F4F2.1070307@univ-mlv.fr> <4D8A00C3.3010204@oracle.com> Message-ID: <4D8A02A9.2070808@univ-mlv.fr> On 03/23/2011 03:16 PM, Alan Bateman wrote: > R?mi Forax wrote: >> >> In my opinion, you should decouple LinkOption from the type used in >> toRealPath >> to allow to specify any other options (not only link options). >> I propose to introduce PathResolverOption as a supertype of LinkOption >> with toRealPath declared toRealPath(PathResolverOption... options). > Do you have other examples in mind? I'd prefer not introduce another > type for this and I'm wondering if these other examples are really > something toRealPath should be supporting or not. MATCH_USER_HOME or MATCH_PWD. In that case, if the path is a subpath of the path defined as user.home (or as pwd), toRealPath() will be done only on the part after the user.home. So even if the user.home is defined using a link, toRealPath() will keep that link. > > -Alan R?mi From Alan.Bateman at oracle.com Wed Mar 23 07:48:55 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Mar 2011 14:48:55 +0000 Subject: 7029979: (fs) Path.toRealPath(boolean) should be toRealPath(LinkOption...) In-Reply-To: <4D8A02A9.2070808@univ-mlv.fr> References: <4D89E992.2010509@oracle.com> <4D89F4F2.1070307@univ-mlv.fr> <4D8A00C3.3010204@oracle.com> <4D8A02A9.2070808@univ-mlv.fr> Message-ID: <4D8A0857.7090800@oracle.com> R?mi Forax wrote: > : > MATCH_USER_HOME or MATCH_PWD. In that case, if the path is a subpath > of the path > defined as user.home (or as pwd), toRealPath() will be done only on > the part after the user.home. > So even if the user.home is defined using a link, toRealPath() will > keep that link. > The toRealPath method is intended to work like realpath(3C) (or File's getCanonicalFile for the case that the file exists). If I understand these examples correctly then they could be implemented using toRealPath and relativize. I think it be best not to burden this method with other use-cases. -Alan. From xueming.shen at oracle.com Thu Mar 24 15:30:15 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 24 Mar 2011 15:30:15 -0700 Subject: 7029979: (fs) Path.toRealPath(boolean) should be toRealPath(LinkOption...) In-Reply-To: <4D89E992.2010509@oracle.com> References: <4D89E992.2010509@oracle.com> Message-ID: <4D8BC5F7.50402@oracle.com> On 03-23-2011 5:37 AM, Alan Bateman wrote: > > Early versions of the file system API used a boolean parameter to > indicate if symbolic links should be followed or not. These methods > has long been changed to use LinkOption and the varargs syntax. There > is one remaining method in the API that still uses a boolean and I'd > like to get this cleaned up before the doors close on jdk7. The method > is Path.toRealPath where the parameter indicates if symbolic links are > resolved or not. The webrev with the proposal is here: > http://cr.openjdk.java.net/~alanb/7029979/webrev/ > > (Sherman - I've included an updated to the zip provider as it is > impacted by this change). > > -Alan The change looks fine. -Sherman From forax at univ-mlv.fr Sat Mar 26 13:43:12 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sat, 26 Mar 2011 21:43:12 +0100 Subject: Bug in Channels.newChannel() ? Message-ID: <4D8E4FE0.2090303@univ-mlv.fr> This snippet prints 2 and 0 ByteArrayInputStream input = new ByteArrayInputStream(new byte[] {1, 2}); ReadableByteChannel channel = Channels.newChannel(input); ByteBuffer buffer = ByteBuffer.allocate(2); System.out.println(channel.read(buffer)); System.out.println(channel.read(buffer)); but should prints 2 and -1 because we reach the end of the stream. R?mi From Alan.Bateman at oracle.com Sun Mar 27 06:07:42 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 27 Mar 2011 14:07:42 +0100 Subject: Bug in Channels.newChannel() ? In-Reply-To: <4D8E4FE0.2090303@univ-mlv.fr> References: <4D8E4FE0.2090303@univ-mlv.fr> Message-ID: <4D8F369E.7070802@oracle.com> R?mi Forax wrote: > This snippet prints 2 and 0 > > ByteArrayInputStream input = new ByteArrayInputStream(new byte[] > {1, 2}); > ReadableByteChannel channel = Channels.newChannel(input); > > ByteBuffer buffer = ByteBuffer.allocate(2); > System.out.println(channel.read(buffer)); > System.out.println(channel.read(buffer)); > > but should prints 2 and -1 because we reach the end of the stream. > > R?mi > The second read is with a buffer that has 0 bytes remaining and so there isn't any read from the underlying input stream. It would be the same thing as reading from the input stream with a zero length byte array. -Alan. From forax at univ-mlv.fr Sun Mar 27 06:12:32 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 27 Mar 2011 15:12:32 +0200 Subject: Bug in Channels.newChannel() ? In-Reply-To: <4D8F369E.7070802@oracle.com> References: <4D8E4FE0.2090303@univ-mlv.fr> <4D8F369E.7070802@oracle.com> Message-ID: <4D8F37C0.9060109@univ-mlv.fr> On 03/27/2011 03:07 PM, Alan Bateman wrote: > R?mi Forax wrote: >> This snippet prints 2 and 0 >> >> ByteArrayInputStream input = new ByteArrayInputStream(new byte[] >> {1, 2}); >> ReadableByteChannel channel = Channels.newChannel(input); >> >> ByteBuffer buffer = ByteBuffer.allocate(2); >> System.out.println(channel.read(buffer)); >> System.out.println(channel.read(buffer)); >> >> but should prints 2 and -1 because we reach the end of the stream. >> >> R?mi >> > The second read is with a buffer that has 0 bytes remaining and so > there isn't any read from the underlying input stream. It would be the > same thing as reading from the input stream with a zero length byte > array. The equivalent code using the InputStream: ByteArrayInputStream input2 = new ByteArrayInputStream(new byte[] {1, 2}); System.out.println(input2.read(new byte[2])); System.out.println(input2.read(new byte[0])); prints 2 and -1. So even if the bytebuffer has no remaining bytes, it should call read. > > -Alan. R?mi From Alan.Bateman at oracle.com Sun Mar 27 06:23:51 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 27 Mar 2011 14:23:51 +0100 Subject: Bug in Channels.newChannel() ? In-Reply-To: <4D8F37C0.9060109@univ-mlv.fr> References: <4D8E4FE0.2090303@univ-mlv.fr> <4D8F369E.7070802@oracle.com> <4D8F37C0.9060109@univ-mlv.fr> Message-ID: <4D8F3A67.8060800@oracle.com> R?mi Forax wrote: > : > The equivalent code using the InputStream: > > ByteArrayInputStream input2 = new ByteArrayInputStream(new byte[] > {1, 2}); > System.out.println(input2.read(new byte[2])); > System.out.println(input2.read(new byte[0])); > > prints 2 and -1. > > So even if the bytebuffer has no remaining bytes, it should call read. This seems to an oddity with ByteArrayInputStream as calling InputStream.read with a zero length byte array should return 0. If you invoke a channel's read method with a buffer that has zero bytes remaining then it should return 0, it can't from the channel (or the underlying input stream in this case) because there is nowhere to put any bytes that is reads. -Alan. From Alan.Bateman at oracle.com Sun Mar 27 10:16:45 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 27 Mar 2011 18:16:45 +0100 Subject: Bug in Channels.newChannel() ? In-Reply-To: <4D8F37C0.9060109@univ-mlv.fr> References: <4D8E4FE0.2090303@univ-mlv.fr> <4D8F369E.7070802@oracle.com> <4D8F37C0.9060109@univ-mlv.fr> Message-ID: <4D8F70FD.6060008@oracle.com> R?mi Forax wrote: > : > > ByteArrayInputStream input2 = new ByteArrayInputStream(new byte[] > {1, 2}); > System.out.println(input2.read(new byte[2])); > System.out.println(input2.read(new byte[0])); > > prints 2 and -1. As it happens I submitted a bug against java.io.ByteArrayInputStream some time ago on this: http://bugs.sun.com/view_bug.do?bug_id=6766844 I'd forgotten about that one. -Alan. From forax at univ-mlv.fr Sun Mar 27 11:39:03 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 27 Mar 2011 20:39:03 +0200 Subject: Bug in Channels.newChannel() ? In-Reply-To: <4D8F70FD.6060008@oracle.com> References: <4D8E4FE0.2090303@univ-mlv.fr> <4D8F369E.7070802@oracle.com> <4D8F37C0.9060109@univ-mlv.fr> <4D8F70FD.6060008@oracle.com> Message-ID: <4D8F8447.7070104@univ-mlv.fr> On 03/27/2011 07:16 PM, Alan Bateman wrote: > R?mi Forax wrote: >> : >> >> ByteArrayInputStream input2 = new ByteArrayInputStream(new byte[] >> {1, 2}); >> System.out.println(input2.read(new byte[2])); >> System.out.println(input2.read(new byte[0])); >> >> prints 2 and -1. > As it happens I submitted a bug against java.io.ByteArrayInputStream > some time ago on this: > http://bugs.sun.com/view_bug.do?bug_id=6766844 > > I'd forgotten about that one. > > -Alan. Ok, I've re-read the javadoc of InputStream.read(), you're right. I think the doc of ReadableByteChannel can be improved to say that read returns 0 if buffer.hasRemaining() returns 0. I propose: "An attempt is made to read up to /r/ bytes from the channel, where /r/ is the number of bytes remaining in the buffer, that is, dst.remaining(), at the moment this method is invoked. If dst.hasRemaining() is false, then no bytes are read and read returns |0. | R?mi| | || -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110327/1357a14c/attachment.html