From Alan.Bateman at oracle.com Mon Nov 3 14:06:56 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 03 Nov 2014 14:06:56 +0000 Subject: 8062632: (fs spec) Package description could be clearer on the cases where NPE is thrown Message-ID: <54578C00.1020404@oracle.com> I need a Reviewer for some trivial updates to the javadoc to address these issues: 8062632: (fs spec) Package description could be clearer on the cases where NPE is thrown 8062553: (fs spec) Files.write and newBufferedWriter methods missing @throws IAE The first is just a two word adjustment to the spec on when NullPointerException is thrown. The second is that the write and newBufferedWriter methods are missing the @throws IllegalArgument. http://cr.openjdk.java.net/~alanb/8062632%2b8062553/webrev/ Thanks, Alan From daniel.fuchs at oracle.com Mon Nov 3 14:33:29 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 03 Nov 2014 15:33:29 +0100 Subject: 8062632: (fs spec) Package description could be clearer on the cases where NPE is thrown In-Reply-To: <54578C00.1020404@oracle.com> References: <54578C00.1020404@oracle.com> Message-ID: <54579239.2060104@oracle.com> Lools good to me Alan. -- daniel On 03/11/14 15:06, Alan Bateman wrote: > > I need a Reviewer for some trivial updates to the javadoc to address > these issues: > > 8062632: (fs spec) Package description could be clearer on the cases > where NPE is thrown > 8062553: (fs spec) Files.write and newBufferedWriter methods missing > @throws IAE > > The first is just a two word adjustment to the spec on when > NullPointerException is thrown. The second is that the write and > newBufferedWriter methods are missing the @throws IllegalArgument. > > http://cr.openjdk.java.net/~alanb/8062632%2b8062553/webrev/ > > Thanks, > > Alan From Kirk.Shoop at microsoft.com Wed Nov 5 17:50:24 2014 From: Kirk.Shoop at microsoft.com (Kirk Shoop (MS OPEN TECH)) Date: Wed, 5 Nov 2014 17:50:24 +0000 Subject: Improving perf of FileChannel.transferTo() on Windows In-Reply-To: References: <543E2650.4000800@oracle.com> <543EB3AC.7060509@oracle.com> <3DE7924A81E09744BF23737394AB479710647451@SINEX14MBXC424.southpacific.corp.microsoft.com> <5445225C.6000307@oracle.com> <3DE7924A81E09744BF23737394AB479710647748@SINEX14MBXC424.southpacific.corp.microsoft.com> <5446B920.5060201@oracle.com> Message-ID: From: nio-dev [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Kirk Shoop (MS OPEN TECH) From: Alan Bateman [mailto:Alan.Bateman at oracle.com] . . . Are you going to update the patch to only use this path when the SocketChannel is configured blocking? Yes, we will post a new webrev when we have changed the code to only apply to blocking sockets. Here is the new webrev. https://openjdkcontrib.blob.core.windows.net/transferto/webrev-20141105.zip We also tried to apply what we learned from the previous submission, so this one uses "jdk.net.enableFastFileTransfer" as the setting name, allows -Djdk.net.enableFastFileTransfer to enable the setting and adds a test that uses the setting. Thanks, Kirk Developer Microsoft Open Technologies, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Thu Nov 6 16:13:38 2014 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Thu, 06 Nov 2014 16:13:38 +0000 Subject: Improving perf of FileChannel.transferTo() on Windows In-Reply-To: References: <543E2650.4000800@oracle.com> <543EB3AC.7060509@oracle.com> <3DE7924A81E09744BF23737394AB479710647451@SINEX14MBXC424.southpacific.corp.microsoft.com> <5445225C.6000307@oracle.com> <3DE7924A81E09744BF23737394AB479710647748@SINEX14MBXC424.southpacific.corp.microsoft.com> <5446B920.5060201@oracle.com> Message-ID: <545B9E32.7080307@oracle.com> Can we get a JBS record logged to track this effort ? It's useful to match requests to JBS numbers. There was over 20 mails exchanged on the TCP Loopback fast path enhancement but no mention of the bug seems have been captured in the Subject (JDK-8060170) Thanks, Sean. On 05/11/2014 17:50, Kirk Shoop (MS OPEN TECH) wrote: > > *From:*nio-dev [mailto:nio-dev-bounces at openjdk.java.net] *On Behalf Of > *Kirk Shoop (MS OPEN TECH) > > *From:*Alan Bateman [mailto:Alan.Bateman at oracle.com] > > . . . > Are you going to update the patch to only use this path when the > SocketChannel is configured blocking? > > Yes, we will post a new webrev when we have changed the code to only > apply to blocking sockets. > > Here is the new webrev. > > https://openjdkcontrib.blob.core.windows.net/transferto/webrev-20141105.zip > > We also tried to apply what we learned from the previous submission, > so this one uses ?jdk.net.enableFastFileTransfer? as the setting name, > allows -Djdk.net.enableFastFileTransfer to enable the setting and adds > a test that uses the setting. > > Thanks, > > Kirk > > Developer > > Microsoft Open Technologies, Inc. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Nov 6 16:19:44 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 06 Nov 2014 16:19:44 +0000 Subject: Improving perf of FileChannel.transferTo() on Windows In-Reply-To: <545B9E32.7080307@oracle.com> References: <543E2650.4000800@oracle.com> <543EB3AC.7060509@oracle.com> <3DE7924A81E09744BF23737394AB479710647451@SINEX14MBXC424.southpacific.corp.microsoft.com> <5445225C.6000307@oracle.com> <3DE7924A81E09744BF23737394AB479710647748@SINEX14MBXC424.southpacific.corp.microsoft.com> <5446B920.5060201@oracle.com> <545B9E32.7080307@oracle.com> Message-ID: <545B9FA0.3090303@oracle.com> On 06/11/2014 16:13, Se?n Coffey wrote: > Can we get a JBS record logged to track this effort ? It's useful to > match requests to JBS numbers. > > There was over 20 mails exchanged on the TCP Loopback fast path > enhancement but no mention of the bug seems have been captured in the > Subject (JDK-8060170) > I'll create an issue for this soon. In the mean-time I want to think about a cleaner way that this can work without needing to touch the Unix code. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sat Nov 8 12:44:07 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 08 Nov 2014 12:44:07 +0000 Subject: Improving perf of FileChannel.transferTo() on Windows In-Reply-To: References: <543E2650.4000800@oracle.com> <543EB3AC.7060509@oracle.com> <3DE7924A81E09744BF23737394AB479710647451@SINEX14MBXC424.southpacific.corp.microsoft.com> <5445225C.6000307@oracle.com> <3DE7924A81E09744BF23737394AB479710647748@SINEX14MBXC424.southpacific.corp.microsoft.com> <5446B920.5060201@oracle.com> Message-ID: <545E1017.5040603@oracle.com> On 05/11/2014 17:50, Kirk Shoop (MS OPEN TECH) wrote: > > Here is the new webrev. > > https://openjdkcontrib.blob.core.windows.net/transferto/webrev-20141105.zip > > We also tried to apply what we learned from the previous submission, > so this one uses "jdk.net.enableFastFileTransfer" as the setting name, > allows -Djdk.net.enableFastFileTransfer to enable the setting and adds > a test that uses the setting. > > I've created JDK-8064407 to track this. One idea to integrate this is to add a canTransferTo(SelectableChannel) method to sun.nio.ch.FileDispatcher. That way the check for whether the channel is blocking and the other Windows-specific configuration can go into the Windows FileDispatcherImpl (keep it out of FileChannelImpl needing native methods for the other platforms). One other point is that trasnferTo is specified not to change the channel's position. This means you will need to synchronize on the positionLock and restore the channel position after the TransmitFile. I don't know if you've figured out how to run jtreg to run tests but if you run the :jdk_nio group and specify -vmoption:-Djdk.net.enableFastFileTransfer=true to jtreg then you'll run all the relevant tests with this option. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kirk.Shoop at microsoft.com Tue Nov 11 18:04:44 2014 From: Kirk.Shoop at microsoft.com (Kirk Shoop (MS OPEN TECH)) Date: Tue, 11 Nov 2014 18:04:44 +0000 Subject: Improving perf of FileChannel.transferTo() on Windows In-Reply-To: <545E1017.5040603@oracle.com> References: <543E2650.4000800@oracle.com> <543EB3AC.7060509@oracle.com> <3DE7924A81E09744BF23737394AB479710647451@SINEX14MBXC424.southpacific.corp.microsoft.com> <5445225C.6000307@oracle.com> <3DE7924A81E09744BF23737394AB479710647748@SINEX14MBXC424.southpacific.corp.microsoft.com> <5446B920.5060201@oracle.com> <545E1017.5040603@oracle.com> Message-ID: <47cfbda045694bfca3ab2eda25f63282@BLUPR03MB136.namprd03.prod.outlook.com> From: Alan Bateman [mailto:Alan.Bateman at oracle.com] I've created JDK-8064407 to track this. Thanks! Feel free to ask/teach us to open these in the future. One idea to integrate this is to add a canTransferTo(SelectableChannel) method to sun.nio.ch.FileDispatcher. That way the check for whether the channel is blocking and the other Windows-specific configuration can go into the Windows FileDispatcherImpl (keep it out of FileChannelImpl needing native methods for the other platforms). One other point is that trasnferTo is specified not to change the channel's position. This means you will need to synchronize on the positionLock and restore the channel position after the TransmitFile. I don't know if you've figured out how to run jtreg to run tests but if you run the :jdk_nio group and specify -vmoption:-Djdk.net.enableFastFileTransfer=true to jtreg then you'll run all the relevant tests with this option. Valery applied both of your suggestions and was able to run the jtreg tests with this new webrev: https://openjdkcontrib.blob.core.windows.net/transferto/webrev-20141111.zip Thanks! Kirk Developer Microsoft Open Technologies, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Nov 13 18:03:34 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 13 Nov 2014 18:03:34 +0000 Subject: Improving perf of FileChannel.transferTo() on Windows In-Reply-To: <47cfbda045694bfca3ab2eda25f63282@BLUPR03MB136.namprd03.prod.outlook.com> References: <543E2650.4000800@oracle.com> <543EB3AC.7060509@oracle.com> <3DE7924A81E09744BF23737394AB479710647451@SINEX14MBXC424.southpacific.corp.microsoft.com> <5445225C.6000307@oracle.com> <3DE7924A81E09744BF23737394AB479710647748@SINEX14MBXC424.southpacific.corp.microsoft.com> <5446B920.5060201@oracle.com> <545E1017.5040603@oracle.com> <47cfbda045694bfca3ab2eda25f63282@BLUPR03MB136.namprd03.prod.outlook.com> Message-ID: <5464F276.8040800@oracle.com> On 11/11/2014 18:04, Kirk Shoop (MS OPEN TECH) wrote: > > > Valery applied both of your suggestions and was able to run the jtreg > tests with this new webrev: > > https://openjdkcontrib.blob.core.windows.net/transferto/webrev-20141111.zip > > I think this looks much better. One thing that needs a closer look is the loop around TransmitFile. If it fails on the second or subsequent call then transferTo will fail after already sending transmitting bytes. For transferTo then it's okay to complete without having transmitted all bytes and maybe it would be better to just cap it at 2GB. Any robust code using transferTo should check the return value. (BTW: You can use java_lang_Integer_MAX_VALUE to avoid the repeating the constant). In transferToDirectly then I don't think you need to check if the target is a SelectableChannel if you move call to nd.canTransferToDirectly to just above where it handles SelChImpl. One suggestion is to top transferToDirectlyEnabledand instead jave canTransferToDirectlyreturn true then the property is enabled and the target change is SelectableChannel configured blocking. A minor comment is that transferToDirectlyChangesChannelPositionis a bit inconsistent with methods like needPositionLock so you might be able to come up with something a bit closer to that, transferDirectNeedsPositionLock maybe? A few style/formatting issues that we can sort out later, otherwise the approach looks okay to me. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kirk.Shoop at microsoft.com Fri Nov 14 16:51:43 2014 From: Kirk.Shoop at microsoft.com (Kirk Shoop (MS OPEN TECH)) Date: Fri, 14 Nov 2014 16:51:43 +0000 Subject: Improving perf of FileChannel.transferTo() on Windows In-Reply-To: <5464F276.8040800@oracle.com> References: <543E2650.4000800@oracle.com> <543EB3AC.7060509@oracle.com> <3DE7924A81E09744BF23737394AB479710647451@SINEX14MBXC424.southpacific.corp.microsoft.com> <5445225C.6000307@oracle.com> <3DE7924A81E09744BF23737394AB479710647748@SINEX14MBXC424.southpacific.corp.microsoft.com> <5446B920.5060201@oracle.com> <545E1017.5040603@oracle.com> <47cfbda045694bfca3ab2eda25f63282@BLUPR03MB136.namprd03.prod.outlook.com> <5464F276.8040800@oracle.com> Message-ID: From: Alan Bateman [mailto:Alan.Bateman at oracle.com] I think this looks much better. Great! One thing that needs a closer look is the loop around TransmitFile. If it fails on the second or subsequent call then transferTo will fail after already sending transmitting bytes. For transferTo then it's okay to complete without having transmitted all bytes and maybe it would be better to just cap it at 2GB. Any robust code using transferTo should check the return value. (BTW: You can use java_lang_Integer_MAX_VALUE to avoid the repeating the constant). Good point, Valery removed the loop. In transferToDirectly then I don't think you need to check if the target is a SelectableChannel if you move call to nd.canTransferToDirectly to just above where it handles SelChImpl. Done. One suggestion is to top transferToDirectlyEnabled and instead jave canTransferToDirectly return true then the property is enabled and the target change is SelectableChannel configured blocking. Done. A minor comment is that transferToDirectlyChangesChannelPosition is a bit inconsistent with methods like needPositionLock so you might be able to come up with something a bit closer to that, transferDirectNeedsPositionLock maybe? Valery chose 'transferToDirectlyNeedsPositionRestoring', but this can be changed. While looking at this, I wondered, could the position lock and position manipulation in Java be skipped altogether if 'Java_sun_nio_ch_FileChannelImpl_transferTo0' used 'Java_sun_nio_ch_FileChannelImpl_position0' to restore the position to the original point? A few style/formatting issues that we can sort out later, otherwise the approach looks okay to me. Happy to take those changes anytime. Here is the new webrev: https://openjdkcontrib.blob.core.windows.net/transferto/webrev-20141114.zip Kirk Developer Microsoft Open Technologies, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sun Nov 23 10:15:38 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 23 Nov 2014 10:15:38 +0000 Subject: Improving perf of FileChannel.transferTo() on Windows In-Reply-To: References: <543E2650.4000800@oracle.com> <543EB3AC.7060509@oracle.com> <3DE7924A81E09744BF23737394AB479710647451@SINEX14MBXC424.southpacific.corp.microsoft.com> <5445225C.6000307@oracle.com> <3DE7924A81E09744BF23737394AB479710647748@SINEX14MBXC424.southpacific.corp.microsoft.com> <5446B920.5060201@oracle.com> <545E1017.5040603@oracle.com> <47cfbda045694bfca3ab2eda25f63282@BLUPR03MB136.namprd03.prod.outlook.com> <5464F276.8040800@oracle.com> Message-ID: <5471B3CA.6030908@oracle.com> On 14/11/2014 16:51, Kirk Shoop (MS OPEN TECH) wrote: > > *From:*Alan Bateman [mailto:Alan.Bateman at oracle.com] > > I think this looks much better. > > Great! > > > One thing that needs a closer look is the loop around TransmitFile. If > it fails on the second or subsequent call then transferTo will fail > after already sending transmitting bytes. For transferTo then it's > okay to complete without having transmitted all bytes and maybe it > would be better to just cap it at 2GB. Any robust code using > transferTo should check the return value. (BTW: You can use > java_lang_Integer_MAX_VALUE to avoid the repeating the constant). > > Good point, Valery removed the loop. > > > In transferToDirectly then I don't think you need to check if the > target is a SelectableChannel if you move call to > nd.canTransferToDirectly to just above where it handles SelChImpl. > > Done. > > > One suggestion is to top transferToDirectlyEnabled and instead jave > canTransferToDirectly return true then the property is enabled and the > target change is SelectableChannel configured blocking. > > Done. > > > A minor comment is that transferToDirectlyChangesChannelPosition is a > bit inconsistent with methods like needPositionLock so you might be > able to come up with something a bit closer to that, > transferDirectNeedsPositionLock maybe? > > Valery chose 'transferToDirectlyNeedsPositionRestoring', but this can > be changed. > > While looking at this, I wondered, could the position lock and > position manipulation in Java be skipped altogether if > 'Java_sun_nio_ch_FileChannelImpl_transferTo0' used > 'Java_sun_nio_ch_FileChannelImpl_position0' to restore the position to > the original point? > > > A few style/formatting issues that we can sort out later, otherwise > the approach looks okay to me. > > Happy to take those changes anytime. > > > Sorry for the delay getting back to you on this, I've been busy with other things. I think the updated version looks good and you've addressed the issues that I was concerned about. One other potential issue that came to mind later is that the blocking mode of the SocketChannel could change to non-blocking at or around the time that transferTo is called. It would be possible to restructure this to hold the blockingLock but I think it makes the locking more complicated. Worst case with this "bug" is that transferTo blocks at around the time the blocking mode is changed to non-blocking. There is a bigger (and longstanding) issue in this area related to async close of the target channel during a transfer and if/when that gets looked at then I think it is the time to address the blocking lock issue too. I had to re-base your patch to get it working with the current jdk9/dev tip, that is only because of other recent changes in this area. I tweaked some minor formatting issues and used the opportunity to replace the imports that use wildcards. I don't have a strong opinion on the method to determine if the position changes except that transferToDirectlyNeedsPositionLock is a bit more consistent with the current naming. Here is the updated patch (only minor edits as I said): http://cr.openjdk.java.net/~alanb/8064407/webrev/ I've run this patch through our build+test system to make sure that it works on the 7+ platforms that we normally care about and I don't see any issues. I've also run the jdk_nio tests with the property enabled so that all tests using transferTo use TransmitFile when the channel is configured blocking. Let me know if you are okay with this? -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sun Nov 23 19:28:59 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 23 Nov 2014 19:28:59 +0000 Subject: 8065720: (ch) AbstractInterruptibleChannel.end sets interrupted to null Message-ID: <5472357B.8010602@oracle.com> I need a reviewer for a change to AbstractInterruptibleChannel::end that Paul Sandoz noticed when looking at this code. AbstractInterruptibleChannel.interrupted is set to the target thread when an operation on channel is interrupted. The end method doesn't need to reset it but it does to avoid keeping a reference to the Thread. The fix is trivial and a remind of the hazards of having locals with the same name as fields. -Alan diff --git a/src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java b/src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java --- a/src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java +++ b/src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java @@ -198,7 +198,7 @@ blockedOn(null); Thread interrupted = this.interrupted; if (interrupted != null && interrupted == Thread.currentThread()) { - interrupted = null; + this.interrupted = null; throw new ClosedByInterruptException(); } if (!completed && !open) From Alan.Bateman at oracle.com Sun Nov 23 19:37:11 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 23 Nov 2014 19:37:11 +0000 Subject: 8062955: (fs spec) Files.setLastModifiedTime should specify SecurityException more clearer Message-ID: <54723767.8080708@oracle.com> This issue is a complaint about the wording of the SecurityException that Files.setLastModifiedTime can throw, also a complaint that the @return doesn't make it clear that it's the given path that is returned (as this method doesn't have an obvious return value). While looking at this method I see that we don't have any test coverage so I've added a test for it (the underlying implementation is well covered, it's just the one-line method in Files that wasn't tested). The webrev with the proposed changes is here: http://cr.openjdk.java.net/~alanb/8062955/webrev/ Thanks, Alan From paul.sandoz at oracle.com Mon Nov 24 10:14:48 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 24 Nov 2014 11:14:48 +0100 Subject: 8065720: (ch) AbstractInterruptibleChannel.end sets interrupted to null In-Reply-To: <5472357B.8010602@oracle.com> References: <5472357B.8010602@oracle.com> Message-ID: On Nov 23, 2014, at 8:28 PM, Alan Bateman wrote: > > I need a reviewer for a change to AbstractInterruptibleChannel::end that Paul Sandoz noticed when looking at this code. > Looks good, Paul. > AbstractInterruptibleChannel.interrupted is set to the target thread when an operation on channel is interrupted. The end method doesn't need to reset it but it does to avoid keeping a reference to the Thread. The fix is trivial and a remind of the hazards of having locals with the same name as fields. > > -Alan > > > diff --git a/src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java b/src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java > --- a/src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java > +++ b/src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java > @@ -198,7 +198,7 @@ > blockedOn(null); > Thread interrupted = this.interrupted; > if (interrupted != null && interrupted == Thread.currentThread()) { > - interrupted = null; > + this.interrupted = null; > throw new ClosedByInterruptException(); > } > if (!completed && !open) > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From chris.hegarty at oracle.com Mon Nov 24 10:36:29 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 24 Nov 2014 10:36:29 +0000 Subject: 8065720: (ch) AbstractInterruptibleChannel.end sets interrupted to null In-Reply-To: References: <5472357B.8010602@oracle.com> Message-ID: <54730A2D.7090303@oracle.com> On 24/11/14 10:14, Paul Sandoz wrote: > > On Nov 23, 2014, at 8:28 PM, Alan Bateman wrote: > >> >> I need a reviewer for a change to AbstractInterruptibleChannel::end that Paul Sandoz noticed when looking at this code. >> > > Looks good, +1. -Chris. > Paul. > >> AbstractInterruptibleChannel.interrupted is set to the target thread when an operation on channel is interrupted. The end method doesn't need to reset it but it does to avoid keeping a reference to the Thread. The fix is trivial and a remind of the hazards of having locals with the same name as fields. >> >> -Alan >> >> >> diff --git a/src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java b/src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java >> --- a/src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java >> +++ b/src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java >> @@ -198,7 +198,7 @@ >> blockedOn(null); >> Thread interrupted = this.interrupted; >> if (interrupted != null && interrupted == Thread.currentThread()) { >> - interrupted = null; >> + this.interrupted = null; >> throw new ClosedByInterruptException(); >> } >> if (!completed && !open) >> > From brian.burkhalter at oracle.com Thu Nov 27 00:35:38 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 26 Nov 2014 16:35:38 -0800 Subject: 8025619: (fc) FileInputStream.getChannel on closed stream returns FileChannel that doesn't know that stream is closed Message-ID: <8E69D78D-79E6-485E-A0A1-AEDDD801ED7B@oracle.com> Please review at your convenience: Issue: https://bugs.openjdk.java.net/browse/JDK-8025619 Patch: http://cr.openjdk.java.net/~bpb/8025619/webrev.00/ This patch fixes the immediate problem encountered by the test included in the issue description. The fix is simply for FileKey.create() to throw an IOException directly instead of wrapping it in an Error. This raises the question of whether some additional verbiage in the description of getChannel() might be necessary to remind that calling close() on the source object will render the FileChannel inviable and possibly cause unforeseen subsequent exceptions. Also, as noted in the issue comments, it begs the question as to whether getChannel() in FileInputStream, FileOutputStream, RendomAccessFile, etc., should return null or throw an IOException if the object on which it is invoked has already been closed. If so this would need to be addressed by an issue yet to be filed and would imply a documentation change. Thanks, Brian From Alan.Bateman at oracle.com Thu Nov 27 08:19:01 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 27 Nov 2014 08:19:01 +0000 Subject: 8025619: (fc) FileInputStream.getChannel on closed stream returns FileChannel that doesn't know that stream is closed In-Reply-To: <8E69D78D-79E6-485E-A0A1-AEDDD801ED7B@oracle.com> References: <8E69D78D-79E6-485E-A0A1-AEDDD801ED7B@oracle.com> Message-ID: <5476DE75.6010909@oracle.com> On 27/11/2014 00:35, Brian Burkhalter wrote: > Please review at your convenience: > > Issue: https://bugs.openjdk.java.net/browse/JDK-8025619 > Patch: http://cr.openjdk.java.net/~bpb/8025619/webrev.00/ > > This patch fixes the immediate problem encountered by the test included in the issue description. The fix is simply for FileKey.create() to throw an IOException directly instead of wrapping it in an Error. > > This raises the question of whether some additional verbiage in the description of getChannel() might be necessary to remind that calling close() on the source object will render the FileChannel inviable and possibly cause unforeseen subsequent exceptions. > > Also, as noted in the issue comments, it begs the question as to whether getChannel() in FileInputStream, FileOutputStream, RendomAccessFile, etc., should return null or throw an IOException if the object on which it is invoked has already been closed. If so this would need to be addressed by an issue yet to be filed and would imply a documentation change. > > I don't think the fix is right, consider for example what would happen if the file descriptor is recycled to another file before tryLock is called. One way to fix this would be to create the FileChannel in getChannel immediately close it (so that FileChannel doesn't leak out in the open state). This will need a bit of work in implCloseChannel, one idea is to have it be a no-op if !fs.valid(). -Alan. From chris.hegarty at oracle.com Fri Nov 28 14:41:14 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 28 Nov 2014 14:41:14 +0000 Subject: 8062955: (fs spec) Files.setLastModifiedTime should specify SecurityException more clearer In-Reply-To: <54723767.8080708@oracle.com> References: <54723767.8080708@oracle.com> Message-ID: <5478898A.6080906@oracle.com> This looks fine to me Alan. Nice to see additional test coverage. -Chris. On 23/11/14 19:37, Alan Bateman wrote: > > This issue is a complaint about the wording of the SecurityException > that Files.setLastModifiedTime can throw, also a complaint that the > @return doesn't make it clear that it's the given path that is returned > (as this method doesn't have an obvious return value). While looking at > this method I see that we don't have any test coverage so I've added a > test for it (the underlying implementation is well covered, it's just > the one-line method in Files that wasn't tested). The webrev with the > proposed changes is here: > http://cr.openjdk.java.net/~alanb/8062955/webrev/ > > Thanks, > > Alan From fgaliegue at gmail.com Sat Nov 29 14:02:28 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Sat, 29 Nov 2014 15:02:28 +0100 Subject: Typo in javadoc of Path's .normalize()? Message-ID: Hello, In the documentation of the returned value of .normalize(), it is said that "[...]an empty path is returned if this path does have a root component and all name elements are redundant". s,does,does not,? It would be logical; for instance, on Unix systems, Paths.get("/.").normalize() returns "/", not "". -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From Alan.Bateman at oracle.com Sat Nov 29 15:09:31 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 29 Nov 2014 15:09:31 +0000 Subject: Typo in javadoc of Path's .normalize()? In-Reply-To: References: Message-ID: <5479E1AB.3060602@oracle.com> On 29/11/2014 14:02, Francis Galiegue wrote: > Hello, > > In the documentation of the returned value of .normalize(), it is said > that "[...]an empty path is returned if this path does have a root > component and all name elements are redundant". > > s,does,does not,? > > It would be logical; for instance, on Unix systems, > Paths.get("/.").normalize() returns "/", not "". > You are right, there is a typo here, this should red "does not have a root component". We'll get this fixed. -Alan From Alan.Bateman at oracle.com Sat Nov 29 15:18:00 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 29 Nov 2014 15:18:00 +0000 Subject: Typo in javadoc of Path's .normalize()? In-Reply-To: <5479E1AB.3060602@oracle.com> References: <5479E1AB.3060602@oracle.com> Message-ID: <5479E3A8.1080409@oracle.com> On 29/11/2014 15:09, Alan Bateman wrote: > On 29/11/2014 14:02, Francis Galiegue wrote: >> Hello, >> >> In the documentation of the returned value of .normalize(), it is said >> that "[...]an empty path is returned if this path does have a root >> component and all name elements are redundant". >> >> s,does,does not,? >> >> It would be logical; for instance, on Unix systems, >> Paths.get("/.").normalize() returns "/", not "". >> > You are right, there is a typo here, this should red "does not have a > root component". We'll get this fixed. I've created JDK-8066196 to track, the diff is trivial and will push to JDK 9 once I get a Reviewer. -Alan. diff --git a/src/java.base/share/classes/java/nio/file/Path.java b/src/java.base/share/classes/java/nio/file/Path.java --- a/src/java.base/share/classes/java/nio/file/Path.java +++ b/src/java.base/share/classes/java/nio/file/Path.java @@ -325,7 +325,7 @@ * * @return the resulting path or this path if it does not contain * redundant name elements; an empty path is returned if this path - * does have a root component and all name elements are redundant + * does not have a root component and all name elements are redundant * * @see #getParent * @see #toRealPath From fgaliegue at gmail.com Sat Nov 29 17:01:42 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Sat, 29 Nov 2014 18:01:42 +0100 Subject: How to .resolve*() and .relativize() Paths which are not issued from the same FileSystem? Message-ID: Hello, I am writing a generic java.nio.file API to allow users to implement FileSystem over various stuff (for instance, DropBox and Google Drive come to mind) but I have trouble with the methods mentioned in the subject. Let us suppose DropBox. I link the provider to URI scheme "dropbox". Now, I create two FileSystems out of the provider, on two different accounts. If I have a path issued from one provider and another issued from the second, at a first glance it does not make any sense to resolve/relativize one against the other. However, the javadoc of java.nio.file only covers the case of different _providers_ for two different paths: "Unless otherwise noted, invoking a method of any class or interface in this package created by one provider with a parameter that is an object created by another provider, will throw ProviderMismatchException." And there is no such exception as FileSystemMismatchException defined; so, how do I handle this case? Do I define this (unchecked) exception? Should the documentation be updated to account for "incompatible" FileSystems? Do I throw ProviderMismatchException anyway? -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From Alan.Bateman at oracle.com Sun Nov 30 09:06:40 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 30 Nov 2014 09:06:40 +0000 Subject: How to .resolve*() and .relativize() Paths which are not issued from the same FileSystem? In-Reply-To: References: Message-ID: <547ADE20.2060102@oracle.com> On 29/11/2014 17:01, Francis Galiegue wrote: > Hello, > > I am writing a generic java.nio.file API to allow users to implement > FileSystem over various stuff (for instance, DropBox and Google Drive > come to mind) but I have trouble with the methods mentioned in the > subject. > > Let us suppose DropBox. I link the provider to URI scheme "dropbox". > > Now, I create two FileSystems out of the provider, on two different > accounts. If I have a path issued from one provider and another issued > from the second, at a first glance it does not make any sense to > resolve/relativize one against the other. I'm curious as to why you would disallow this? They may be to different dropbox accounts but I assume the file path syntax is the same and they have the same internal representation (as they are associated with the same file system provider). So if someone is moving a file from a folder in one dropbox account to another then I would expect it to work and for it not to loose the file name representation as part of the move. -Alan > > However, the javadoc of java.nio.file only covers the case of > different _providers_ for two different paths: "Unless otherwise > noted, invoking a method of any class or interface in this package > created by one provider with a parameter that is an object created by > another provider, will throw ProviderMismatchException." > > And there is no such exception as FileSystemMismatchException defined; > so, how do I handle this case? Do I define this (unchecked) exception? > Should the documentation be updated to account for "incompatible" > FileSystems? Do I throw ProviderMismatchException anyway? > From fgaliegue at gmail.com Sun Nov 30 10:27:07 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Sun, 30 Nov 2014 11:27:07 +0100 Subject: How to .resolve*() and .relativize() Paths which are not issued from the same FileSystem? In-Reply-To: <547ADE20.2060102@oracle.com> References: <547ADE20.2060102@oracle.com> Message-ID: Hello again, On Sun, Nov 30, 2014 at 10:06 AM, Alan Bateman wrote: [...] >> >> Now, I create two FileSystems out of the provider, on two different >> accounts. If I have a path issued from one provider and another issued >> from the second, at a first glance it does not make any sense to >> resolve/relativize one against the other. > > I'm curious as to why you would disallow this? They may be to different > dropbox accounts but I assume the file path syntax is the same and they have > the same internal representation (as they are associated with the same file > system provider). So if someone is moving a file from a folder in one > dropbox account to another then I would expect it to work and for it not to > loose the file name representation as part of the move. > Then what filesystem should the resulting path be associated with? Depending on the arguments, if "other" is returned then we get a path which is not associated with "us"... My initial confusion probably comes from the fact that when I tried to copy a file from a zip filesystem onto the default filesystem, I was unable to resolve the path issued from the zip against the path on disk... I had to .toString() the zip path before resolving :/ -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From Alan.Bateman at oracle.com Sun Nov 30 16:43:12 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 30 Nov 2014 16:43:12 +0000 Subject: How to .resolve*() and .relativize() Paths which are not issued from the same FileSystem? In-Reply-To: References: <547ADE20.2060102@oracle.com> Message-ID: <547B4920.2010105@oracle.com> On 30/11/2014 10:27, Francis Galiegue wrote: > : > Then what filesystem should the resulting path be associated with? > Depending on the arguments, if "other" is returned then we get a path > which is not associated with "us"... It will depend on the argument. Suppose we have: Path p1 = fs1.getPath( ... ); Path p2 = fs2.getPath( ... ); assert fs1.provider() == fs2.provider(); Path p3 = p1.resolve(p2); Suppose p2 is just a file name or a sequence of names (no root component) then the result of p1.resolve(p2) will give you Path in file system fs1. On the other hand, support that p2 is an absolute path then the resolve of p1.resolve(p2) will be p2, hence in file system fs2. From what you've said so far then I can imagine the "dropbox" provider working a bit like the zip provider so trying out these examples with the zip provider should help. > > My initial confusion probably comes from the fact that when I tried to > copy a file from a zip filesystem onto the default filesystem, I was > unable to resolve the path issued from the zip against the path on > disk... I had to .toString() the zip path before resolving :/ This is indeed a problematic topic that we don't have support for in the API. If a Path has a root component then it's not clear how you could convert it to an equivalent Path in the target file system. On the other hand, if a Path does not have a root component then you can convert each of the name elements to String and use resolve to build up the target Path, as in: Path p1 = ... Path p2 = fs2.getPath(""); for (Path name: p1) { p2 = p2.resolve(name.toString()); } Clearly converting the name elements to String may cause you to loose the internal representation (it might be bytes for example) but there doesn't seem to be anything better. -Alan From fgaliegue at gmail.com Sun Nov 30 17:19:43 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Sun, 30 Nov 2014 18:19:43 +0100 Subject: How to .resolve*() and .relativize() Paths which are not issued from the same FileSystem? In-Reply-To: <547B4920.2010105@oracle.com> References: <547ADE20.2060102@oracle.com> <547B4920.2010105@oracle.com> Message-ID: Hello again, On Sun, Nov 30, 2014 at 5:43 PM, Alan Bateman wrote: [...] > > It will depend on the argument. Suppose we have: > > Path p1 = fs1.getPath( ... ); > Path p2 = fs2.getPath( ... ); > assert fs1.provider() == fs2.provider(); > > Path p3 = p1.resolve(p2); > > Suppose p2 is just a file name or a sequence of names (no root component) > then the result of p1.resolve(p2) will give you Path in file system fs1. > > On the other hand, support that p2 is an absolute path then the resolve of > p1.resolve(p2) will be p2, hence in file system fs2. > So far so good, this is what the doc says. And this reminds me of another question I had about that: why does the Path API make a difference between having a root component and being absolute? In other words, is there possibly a case where a Path is absolute but has no root component or the reverse? [...] >> >> My initial confusion probably comes from the fact that when I tried to >> copy a file from a zip filesystem onto the default filesystem, I was >> unable to resolve the path issued from the zip against the path on >> disk... I had to .toString() the zip path before resolving :/ > > This is indeed a problematic topic that we don't have support for in the > API. If a Path has a root component then it's not clear how you could > convert it to an equivalent Path in the target file system. On the other > hand, if a Path does not have a root component then you can convert each of > the name elements to String and use resolve to build up the target Path, as > in: > > Path p1 = ... > Path p2 = fs2.getPath(""); > for (Path name: p1) { > p2 = p2.resolve(name.toString()); > } > > Clearly converting the name elements to String may cause you to loose the > internal representation (it might be bytes for example) but there doesn't > seem to be anything better. > I don't see how this is a problem since the goal is to have a path suitable for the filesystem of p2; I mean, if you resolve against a string, you are supposed to create a path against the target filesystem, right? As such why would the internal representation of p1 matter? -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias) From Alan.Bateman at oracle.com Sun Nov 30 20:43:59 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 30 Nov 2014 20:43:59 +0000 Subject: How to .resolve*() and .relativize() Paths which are not issued from the same FileSystem? In-Reply-To: References: <547ADE20.2060102@oracle.com> <547B4920.2010105@oracle.com> Message-ID: <547B818F.2060600@oracle.com> On 30/11/2014 17:19, Francis Galiegue wrote: > : > > And this reminds me of another question I had about that: why does the > Path API make a difference between having a root component and being > absolute? In other words, is there possibly a case where a Path is > absolute but has no root component or the reverse? The most obvious example is on Windows where paths such "C:foo" and "\foo" have root components but are not absolute paths. > : > > I don't see how this is a problem since the goal is to have a path > suitable for the filesystem of p2; I mean, if you resolve against a > string, you are supposed to create a path against the target > filesystem, right? As such why would the internal representation of p1 > matter? > Converting to a String might be lossy, esp. if the internal representation is bytes. So if p1 and p2 are associated with the same file system provider then you can preserve the internal representation. We don't have a solution for this when converting name elements from one file system provider to another. -Alan From fgaliegue at gmail.com Sun Nov 30 21:47:52 2014 From: fgaliegue at gmail.com (Francis Galiegue) Date: Sun, 30 Nov 2014 22:47:52 +0100 Subject: How to .resolve*() and .relativize() Paths which are not issued from the same FileSystem? In-Reply-To: <547B818F.2060600@oracle.com> References: <547ADE20.2060102@oracle.com> <547B4920.2010105@oracle.com> <547B818F.2060600@oracle.com> Message-ID: Hello again, On Sun, Nov 30, 2014 at 9:43 PM, Alan Bateman wrote: [...] >> >> And this reminds me of another question I had about that: why does the >> Path API make a difference between having a root component and being >> absolute? In other words, is there possibly a case where a Path is >> absolute but has no root component or the reverse? > > The most obvious example is on Windows where paths such "C:foo" and "\foo" > have root components but are not absolute paths. > OK, that makes sense -- however I didn't know that the first path was valid at all; or even whether it can represent anything at all... > >> : >> >> I don't see how this is a problem since the goal is to have a path >> suitable for the filesystem of p2; I mean, if you resolve against a >> string, you are supposed to create a path against the target >> filesystem, right? As such why would the internal representation of p1 >> matter? >> > Converting to a String might be lossy, esp. if the internal representation > is bytes. So if p1 and p2 are associated with the same file system provider > then you can preserve the internal representation. We don't have a solution > for this when converting name elements from one file system provider to > another. > Well, if you cannot convert from/to the necessary byte array, you are supposed to throw an InvalidPathException, correct? In UnixPath I see that a Charset{De,En}coder is used for these purposes with a CodingErrorAction of REPORT. Well, while I'm at it, yet another question... This time this is the doc of .resolveSibling(): "[...]If this path does not have a parent path, or other is absolute, then this method returns other. If other is an empty path then this method returns this path's parent, or where this path doesn't have a parent, the empty path." The last part is rather confusing: "or where this path doesn't have a parent, the empty path". This scenario is in fact already covered by the first part: since the path does not have a parent, other is returned -- even if other is the empty path. And there's even a contradiction there: what is "the empty path"? An empty path attached to the file system of "path" or "other"? On Linux, it returns "other" unconditionally, which says it's the first part which takes precedence. So, should this last part of the documentation be removed? (I'm sure I am missing another question which I had... Ahwell. Sorry for the trouble!) -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/parboiled1/grappa (redde Caesaris: https://github.com/sirthias)