RFR: 8066644: Fix deprecation warnings in jdk.zipfs module (original) (raw)
Claes Redestad claes.redestad at oracle.com
Tue Oct 27 15:37:29 UTC 2015
- Previous message: RFR: 8066644: Fix deprecation warnings in jdk.zipfs module
- Next message: RFR: 8066644: Fix deprecation warnings in jdk.zipfs module
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 2015-10-27 15:09, Claes Redestad wrote:
On 2015-10-27 14:40, Aleksey Shipilev wrote: On 10/24/2015 11:54 PM, Claes Redestad wrote: webrev: bug: https://bugs.openjdk.java.net/browse/JDK-8066644 Looks good.
Is there really no way to use the new DateTime API, and ditch the multiplication by 1000L here? 116 return ldt.toEpochSecond( 117 ZoneId.systemDefault().getRules().getOffset(ldt)) * 1000L; I guess using java.util.concurrent.TimeUnit might suffice: return TimeUnit.MILLISECONDS.convert(ldt.toEpochSecond(...), TimeUnit.SECONDS); The idiomatic DateTime way I guess would be to do: return Duration.ofSeconds(ldt.toEpochSecond(), 0).toMillis(); I'll take these for a spin; properly inlined either variant might be performance neutral.
It seems any difference between the second-to-millisecond conversion approaches is negligible under repeated testing[1], thus I think the preferred approach is to use be Duration.ofSeconds(..).toMillis():
http://cr.openjdk.java.net/~redestad/8066644/webrev.03
Thanks!
/Claes
Benchmark Mode Cnt Score Error Units ZipUtilsTest.dosToJavaTime_Original avgt 25 108.056 ± 1.622 ns/op ZipUtilsTest.dosToJavaTime_Duration avgt 25 105.468 ± 2.076 ns/op ZipUtilsTest.dosToJavaTime_TimeUnit avgt 25 104.318 ± 2.456 ns/op
- Previous message: RFR: 8066644: Fix deprecation warnings in jdk.zipfs module
- Next message: RFR: 8066644: Fix deprecation warnings in jdk.zipfs module
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]