Re: [threeten-develop] JSR 310 Final Release Materials and Review
Status: Alpha
Brought to you by:
scolebourne
From: Stephen C. <sco...@jo...> - 2014-01-23 07:03:41
|
On 22 January 2014 21:24, Douglas Surber <dou...@or...> wrote: > The JavaDoc for Instant.MAX says >>The maximum supported Instant, >>'1000000000-12-31T23:59:59.999999999Z'. > and for Instant.MIN says >>The minimum supported Instant, '-1000000000-01-01T00:00Z'. > This is +/- 1 * 10^9 years which conflicts with the Instant class > description which says: > >>The measurable time-line is restricted to the number of seconds that >>can be held in a long. This is greater than the current estimated >>age of the universe. The size of Instant was reduced to ensure that calculations returned correct numbers. This occurred when Instant was integrated with ZDT etc under the common Temporal interfaces. The two paragraphs above are now a spec error and should be removed. > Long.MAX_VALUE number of seconds is more than +/- 292 * 10^9 years > and the universe is 13.7 * 10^9 years old. > > Given the class description it seems incorrect that > > Instant.MAX.compareTo(Instant.ofEpochSeconds(Long.MAX_VALUE)) > returns -1. Instant.ofEpochSeconds(Long.MAX_VALUE) should throw an exception. Bug if it doesn't. > As an aside, why 'MAX' rather than 'MAX_VALUE' as is used elsewhere? The java.lang.Integer class uses MAX_VALUE to return the equivalent primitive value. ie. Integer.MAX_VALUE returns an int not an Integer. With 310, there is no separate value type, so I used MAX. Stephen > Douglas > > At 01:42 PM 1/17/2014, Roger Riggs wrote: >>Hi, >> >>Please review the >><http://cr.openjdk.java.net/%7Erriggs/datetime-1_0-fr-spec.zip>Final >>Release Specification (zip)[1] and materials. >> >>Updates to the specification since PFD: >> * <https://bugs.openjdk.java.net/browse/JDK-8031103>8031103: >> java.time.Duration has wrong Javadoc Comments in toDays() and >> toHours() >> * The SE 8 javadoc has been used to generate the specification >> so its appearance is a bit different >> >>The code coverage is ~93% using jcov and is considered adequate. >> >>The RI and TCK are the same as for SE 8; since the development of >>the APIs >>and tests has been done via OpenJDK and earlier open source projects >>their contents are will known. >> >>The RI and TCK are being made available to official Expert Group >>members for review >>under a separate email. >> >>The FAB submission to the PMO is planned for 1/29. >> >>Please give your approval to proceed with the Final Release or raise >>any issues >>by Friday Jan 24th. >> >>Thanks, Roger >> >>[1] >><http://cr.openjdk.java.net/~rriggs/datetime-1_0-fr-spec.zip>http://cr.openjdk.java.net/~rriggs/datetime-1_0-fr-spec.zip >> >>------------------------------------------------------------------------------ >>CenturyLink Cloud: The Leader in Enterprise Cloud Services. >>Learn Why More Businesses Are Choosing CenturyLink Cloud For >>Critical Workloads, Development Environments & Everything In >>Between. >>Get a Quote or Start a Free Trial Today. >>http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >> >>_______________________________________________ >>threeten-develop mailing list >>thr...@li... >>https://lists.sourceforge.net/lists/listinfo/threeten-develop > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > threeten-develop mailing list > thr...@li... > https://lists.sourceforge.net/lists/listinfo/threeten-develop |