[threeten-dev] [threeten-develop] JSR 310 Final Release Materials and Review

Stephen Colebourne scolebourne at joda.org
Wed Jan 22 23:03:10 PST 2014


On 22 January 2014 21:24, Douglas Surber <douglas.surber at oracle.com> 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
>>threeten-develop at lists.sourceforge.net
>>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
> threeten-develop at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/threeten-develop


More information about the threeten-dev mailing list