From mlists at juma.me.uk Mon Dec 4 09:22:19 2017 From: mlists at juma.me.uk (Ismael Juma) Date: Mon, 4 Dec 2017 11:22:19 +0200 Subject: JDK-8177809: File.lastModified() is losing milliseconds (always ends in 000) Message-ID: Hi all, The following was stated in JDK-8177809: "File.getLastModified() always returns with second precision, loosing the milliseconds (i.e. a number ending in 000). I tried using Files.getLastModifiedTime and it seems to work correctly." It doesn't look like Files.getLastModifiedTime works correctly either (at least in some cases). I tested Java 10 on macOS High Sierra and APFS and File.getLastModified has better behaviour now: ~ ??? java --version java 10-ea Java(TM) SE Runtime Environment (build 10-ea+30) Java HotSpot(TM) 64-Bit Server VM (build 10-ea+30, mixed mode) jshell> import java.io.File jshell> import java.nio.file.Files jshell> File f = new File("Downloads") f ==> Downloads jshell> Files.getLastModifiedTime(f.toPath()).toMillis() $8 ==> 1512376609000 jshell> f.lastModified() $9 ==> 1512376609808 In the following SBT (Scala build tool) issue, someone tested on Ubuntu 16.04 and Files.getLastModifiedTime had 000 for the milliseconds part while a JNA-based library did not: println(getModifiedTime(filePath)) // native 1512178359814 println(Files.getLastModifiedTime((new File(filePath)).toPath).toMillis) 1512178359000 https://github.com/sbt/io/pull/92#issuecomment-348657222 Since I'm not able to post in the JIRA ticket, I thought I'd report the issue here. It would be unfortunate for File.getLastModified to have better behaviour than Files.getLastModifiedTime in Java 10. Ismael -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Dec 4 12:49:01 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 4 Dec 2017 12:49:01 +0000 Subject: JDK-8177809: File.lastModified() is losing milliseconds (always ends in 000) In-Reply-To: References: Message-ID: On 04/12/2017 09:22, Ismael Juma wrote: > Hi all, > > The following was stated in JDK-8177809: > > "File.getLastModified() always returns with second precision, loosing > the milliseconds (i.e. a number ending in 000). I tried using > Files.getLastModifiedTime and it seems to work correctly." > > It doesn't look like Files.getLastModifiedTime works correctly either > (at least in some cases). I tested Java 10 on macOS High Sierra and > APFS and File.getLastModified has better behaviour now: > Thanks. The changes for JDK-8177809 in JDK 10 need additional changes to the NIO implementation. There was a brief discussion on core-libs-dev recently about this too. -Alan From mlists at juma.me.uk Mon Dec 4 15:41:06 2017 From: mlists at juma.me.uk (Ismael Juma) Date: Mon, 4 Dec 2017 17:41:06 +0200 Subject: JDK-8177809: File.lastModified() is losing milliseconds (always ends in 000) In-Reply-To: References: Message-ID: Thanks Alan. I had a look at the core-libs-dev discussion and it seems like there was a bit of confusion on whether Files.getLastModifiedTime had the right behaviour or not (Ricardo Almeida briefly mentioned that it did not work for him in Ubuntu as you said). It might be worth adding a comment to the JIRA ticket for others who come across it. Cc'd Brian Burkhalter so he's aware that his fix does work in macOS with APFS (it had no effect on HFS+ as expected). :) Ismael On Mon, Dec 4, 2017 at 2:49 PM, Alan Bateman wrote: > On 04/12/2017 09:22, Ismael Juma wrote: > >> Hi all, >> >> The following was stated in JDK-8177809: >> >> "File.getLastModified() always returns with second precision, loosing the >> milliseconds (i.e. a number ending in 000). I tried using >> Files.getLastModifiedTime and it seems to work correctly." >> >> It doesn't look like Files.getLastModifiedTime works correctly either (at >> least in some cases). I tested Java 10 on macOS High Sierra and APFS and >> File.getLastModified has better behaviour now: >> >> Thanks. The changes for JDK-8177809 in JDK 10 need additional changes to > the NIO implementation. There was a brief discussion on core-libs-dev > recently about this too. > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Dec 4 15:47:21 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 4 Dec 2017 15:47:21 +0000 Subject: JDK-8177809: File.lastModified() is losing milliseconds (always ends in 000) In-Reply-To: References: Message-ID: On 04/12/2017 15:41, Ismael Juma wrote: > Thanks Alan. I had a look at the core-libs-dev discussion and it seems > like there was a bit of confusion on whether?Files.getLastModifiedTime > had the right behaviour or not (Ricardo Almeida briefly mentioned that > it did not work for him in Ubuntu as you said). It might be worth > adding a comment to the JIRA ticket for others who come across it. The behavior on Linux should be correct for both methods on JDK 10, except if you build OpenJDK with a very old gcc. The discussion on core-libs-dev was 8uX where different versions of gcc are used. Once this code is updated in JDK 10 then the behavior should be consistent. It will also sort out the issue on OS X (which did not support the higher precision timestamps when originally implemented). -Alan From mlists at juma.me.uk Mon Dec 4 16:01:57 2017 From: mlists at juma.me.uk (Ismael Juma) Date: Mon, 4 Dec 2017 18:01:57 +0200 Subject: JDK-8177809: File.lastModified() is losing milliseconds (always ends in 000) In-Reply-To: References: Message-ID: Thanks for the explanation. Good to know that the gcc version was also a factor (particularly for the 8uX case). Ismael On Mon, Dec 4, 2017 at 5:47 PM, Alan Bateman wrote: > On 04/12/2017 15:41, Ismael Juma wrote: > >> Thanks Alan. I had a look at the core-libs-dev discussion and it seems >> like there was a bit of confusion on whether Files.getLastModifiedTime >> had the right behaviour or not (Ricardo Almeida briefly mentioned that it >> did not work for him in Ubuntu as you said). It might be worth adding a >> comment to the JIRA ticket for others who come across it. >> > The behavior on Linux should be correct for both methods on JDK 10, except > if you build OpenJDK with a very old gcc. The discussion on core-libs-dev > was 8uX where different versions of gcc are used. > > Once this code is updated in JDK 10 then the behavior should be > consistent. It will also sort out the issue on OS X (which did not support > the higher precision timestamps when originally implemented). > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Dec 6 18:03:31 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 6 Dec 2017 10:03:31 -0800 Subject: RFR 8191872: (fs) UnixNativeDispatcher conditionally compiles in support for high precision timestamps Message-ID: https://bugs.openjdk.java.net/browse/JDK-8191872 http://cr.openjdk.java.net/~bpb/8191872/webrev.00/ 1. Add conditional compilation branch for macOS to support higher precision so Files.getLastModifiedTime() has the same milliseconds precision as File.lastModified() which was already updated in JDK 10 [1]. 2. Remove conditional compilation restriction on non-macOS Unix, i.e., (_POSIX_C_SOURCE >= 200809L) || defined(solaris). Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8177809 From Alan.Bateman at oracle.com Wed Dec 6 19:27:19 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 6 Dec 2017 19:27:19 +0000 Subject: RFR 8191872: (fs) UnixNativeDispatcher conditionally compiles in support for high precision timestamps In-Reply-To: References: Message-ID: On 06/12/2017 18:03, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8191872 > http://cr.openjdk.java.net/~bpb/8191872/webrev.00/ > > 1. Add conditional compilation branch for macOS to support higher precision so Files.getLastModifiedTime() has the same milliseconds precision as File.lastModified() which was already updated in JDK 10 [1]. > 2. Remove conditional compilation restriction on non-macOS Unix, i.e., (_POSIX_C_SOURCE >= 200809L) || defined(solaris). > The implementation changes looks good. Are you sure that the test is reliable on Windows? I don't know if anyone runs these tests on FAT32 but I assume it will fail there. -Alan From brian.burkhalter at oracle.com Wed Dec 6 19:31:17 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 6 Dec 2017 11:31:17 -0800 Subject: RFR 8191872: (fs) UnixNativeDispatcher conditionally compiles in support for high precision timestamps In-Reply-To: References: Message-ID: <7C0FAAF6-71A7-47E6-9741-B7864C150439@oracle.com> On Dec 6, 2017, at 11:27 AM, Alan Bateman wrote: > On 06/12/2017 18:03, Brian Burkhalter wrote: >> https://bugs.openjdk.java.net/browse/JDK-8191872 >> http://cr.openjdk.java.net/~bpb/8191872/webrev.00/ >> >> 1. Add conditional compilation branch for macOS to support higher precision so Files.getLastModifiedTime() has the same milliseconds precision as File.lastModified() which was already updated in JDK 10 [1]. >> 2. Remove conditional compilation restriction on non-macOS Unix, i.e., (_POSIX_C_SOURCE >= 200809L) || defined(solaris). >> > The implementation changes looks good. > > Are you sure that the test is reliable on Windows? I don't know if anyone runs these tests on FAT32 but I assume it will fail there. I have not tried FAT32 but it succeeds on all platforms in our regression harness. I did test it on macOS using NFS to verify the higher precision was working correctly. Is it worth testing on FAT32? Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Dec 6 20:43:43 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 6 Dec 2017 20:43:43 +0000 Subject: RFR 8191872: (fs) UnixNativeDispatcher conditionally compiles in support for high precision timestamps In-Reply-To: <7C0FAAF6-71A7-47E6-9741-B7864C150439@oracle.com> References: <7C0FAAF6-71A7-47E6-9741-B7864C150439@oracle.com> Message-ID: On 06/12/2017 19:31, Brian Burkhalter wrote: > > I have not tried FAT32 but it succeeds on all platforms in our > regression harness. I did test it on macOS using NFS to verify the > higher precision was working correctly. > > Is it worth testing on FAT32? > Probably not. Volker or someone in SAP will probably want to test this patch on AIX. I don't know if it will need a follow-up issue. -Alan From brian.burkhalter at oracle.com Wed Dec 6 21:15:24 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 6 Dec 2017 13:15:24 -0800 Subject: RFR 8191872: (fs) UnixNativeDispatcher conditionally compiles in support for high precision timestamps In-Reply-To: References: <7C0FAAF6-71A7-47E6-9741-B7864C150439@oracle.com> Message-ID: On Dec 6, 2017, at 12:43 PM, Alan Bateman wrote: > Volker or someone in SAP will probably want to test this patch on AIX. I don't know if it will need a follow-up issue. I can hold off pushing this until they do so but it should get into JDK 10 I think. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Thu Dec 7 12:53:34 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 7 Dec 2017 13:53:34 +0100 Subject: RFR 8191872: (fs) UnixNativeDispatcher conditionally compiles in support for high precision timestamps In-Reply-To: References: <7C0FAAF6-71A7-47E6-9741-B7864C150439@oracle.com> Message-ID: Hi Brian, thanks for caring for our AIX port. Your change looks good and works fine on AIX. I think it will break on version of AIX older than 7.1 (and the "_POSIX_C_SOURCE >= 200809L)" guard protected against that) but that's no problem as we don't plan to support Java 10 on AIX 6.1 and below :) Regards, Volker On Wed, Dec 6, 2017 at 10:15 PM, Brian Burkhalter wrote: > On Dec 6, 2017, at 12:43 PM, Alan Bateman wrote: > > Volker or someone in SAP will probably want to test this patch on AIX. I > don't know if it will need a follow-up issue. > > > I can hold off pushing this until they do so but it should get into JDK 10 I > think. > > Brian From brian.burkhalter at oracle.com Thu Dec 7 16:57:56 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 7 Dec 2017 08:57:56 -0800 Subject: RFR 8191872: (fs) UnixNativeDispatcher conditionally compiles in support for high precision timestamps In-Reply-To: References: <7C0FAAF6-71A7-47E6-9741-B7864C150439@oracle.com> Message-ID: <8FAE151E-28A5-4D06-9FEB-0D69C4B03AEB@oracle.com> Hi Volker, On Dec 7, 2017, at 4:53 AM, Volker Simonis wrote: > thanks for caring for our AIX port. You?re welcome. Thanks for the quick verification of the patch. > Your change looks good and works fine on AIX. I think it will break on > version of AIX older than 7.1 (and the "_POSIX_C_SOURCE >= 200809L)" > guard protected against that) > but that's no problem as we don't plan to support Java 10 on AIX 6.1 > and below :) Pushed: http://hg.openjdk.java.net/jdk/jdk/rev/b27d2f69e552 Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Tue Dec 19 22:52:17 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 19 Dec 2017 14:52:17 -0800 Subject: RFR 8193842: Replace Files.copy(InputStream, OutputStream) with InputStream.transferTo(OutputStream) Message-ID: https://bugs.openjdk.java.net/browse/JDK-8193842 http://cr.openjdk.java.net/~bpb/8193842/webrev.00/ Replace the private static method cop(InputStream,OutputStream) with recently added public APIs. Thanks, Brian From christoph.langer at sap.com Wed Dec 20 07:12:58 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 20 Dec 2017 07:12:58 +0000 Subject: RFR 8193842: Replace Files.copy(InputStream, OutputStream) with InputStream.transferTo(OutputStream) In-Reply-To: References: Message-ID: Hi Brian, this looks good. Best regards Christoph -----Original Message----- From: nio-dev [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Brian Burkhalter Sent: Dienstag, 19. Dezember 2017 23:52 To: nio-dev Subject: RFR 8193842: Replace Files.copy(InputStream, OutputStream) with InputStream.transferTo(OutputStream) https://bugs.openjdk.java.net/browse/JDK-8193842 http://cr.openjdk.java.net/~bpb/8193842/webrev.00/ Replace the private static method cop(InputStream,OutputStream) with recently added public APIs. Thanks, Brian From Alan.Bateman at oracle.com Wed Dec 20 07:48:03 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 20 Dec 2017 07:48:03 +0000 Subject: RFR 8193842: Replace Files.copy(InputStream, OutputStream) with InputStream.transferTo(OutputStream) In-Reply-To: References: Message-ID: <99b8f28a-73f4-561a-a9a0-4325470243db@oracle.com> On 19/12/2017 22:52, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8193842 > http://cr.openjdk.java.net/~bpb/8193842/webrev.00/ > > Replace the private static method cop(InputStream,OutputStream) with recently added public APIs. > Looks good. -Alan