From roger.riggs at oracle.com  Mon Jan  6 11:11:01 2014
From: roger.riggs at oracle.com (roger riggs)
Date: Mon, 06 Jan 2014 14:11:01 -0500
Subject: [threeten-dev] RFR java.time.Duration spec correction  (8031103)
In-Reply-To: <52CAFF5A.4040106@oracle.com>
References: <52CAFF5A.4040106@oracle.com>
Message-ID: <52CAFFC5.1000606@oracle.com>

Please review this minor specification correction to the 
java.time.Duration.toDays() and
toHours() methods.  Only the javadoc is corrected, no code or tests are 
affected.

Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-duration-javadoc-8031103/

Thanks, Roger

JDK-8031103 <https://bugs.openjdk.java.net/browse/JDK-8031103> 
java.time.Duration has wrong Javadoc Comments in toDays() and toHours()




From jpgough at gmail.com  Tue Jan 14 16:58:52 2014
From: jpgough at gmail.com (James Gough)
Date: Wed, 15 Jan 2014 00:58:52 +0000
Subject: [threeten-dev] Default Method in ChronoLocalDate and usage in
	LocalDate Question
Message-ID: <CAP0svmpsJTXAwuGsh+wnuk4BhJqKgdoRy0zDokYkJuSMk+weCA@mail.gmail.com>

Hi,

This is a question about default methods in java.time in 1.8.0-ea. In
ChronoLocalDate interface the format method is a default method:

    default String format(DateTimeFormatter formatter) {
        Objects.requireNonNull(formatter, "formatter");
        return formatter.format(this);
    }

In LocalDate this default method is overridden with:

    @Override  // override for Javadoc and performance
    public String format(DateTimeFormatter formatter) {
        Objects.requireNonNull(formatter, "formatter");
        return formatter.format(this);
    }

What is the performance benefit of doing this? As it's the same code why
would we not just use the default method implementation?

Regards,
Jim

From scolebourne at joda.org  Wed Jan 15 00:28:05 2014
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 15 Jan 2014 17:28:05 +0900
Subject: [threeten-dev] [threeten-develop] Default Method in
 ChronoLocalDate and usage in LocalDate Question
In-Reply-To: <CAP0svmpsJTXAwuGsh+wnuk4BhJqKgdoRy0zDokYkJuSMk+weCA@mail.gmail.com>
References: <CAP0svmpsJTXAwuGsh+wnuk4BhJqKgdoRy0zDokYkJuSMk+weCA@mail.gmail.com>
Message-ID: <CACzrW9BF1Mwntrxr2FqH234C9OPtfVjcgekBD3jriEYZFXNSmg@mail.gmail.com>

Looks like a cut and paste error in the comment to me...
Stephen

On 15 January 2014 09:58, James Gough <jpgough at gmail.com> wrote:
> Hi,
>
> This is a question about default methods in java.time in 1.8.0-ea. In
> ChronoLocalDate interface the format method is a default method:
>
>     default String format(DateTimeFormatter formatter) {
>         Objects.requireNonNull(formatter, "formatter");
>         return formatter.format(this);
>     }
>
> In LocalDate this default method is overridden with:
>
>     @Override  // override for Javadoc and performance
>     public String format(DateTimeFormatter formatter) {
>         Objects.requireNonNull(formatter, "formatter");
>         return formatter.format(this);
>     }
>
> What is the performance benefit of doing this? As it's the same code why
> would we not just use the default method implementation?
>
> Regards,
> Jim
>
> ------------------------------------------------------------------------------
> 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
>

From jpgough at gmail.com  Wed Jan 15 00:46:03 2014
From: jpgough at gmail.com (James Gough)
Date: Wed, 15 Jan 2014 08:46:03 +0000
Subject: [threeten-dev] [threeten-develop] Default Method in
 ChronoLocalDate and usage in LocalDate Question
In-Reply-To: <CACzrW9BF1Mwntrxr2FqH234C9OPtfVjcgekBD3jriEYZFXNSmg@mail.gmail.com>
References: <CAP0svmpsJTXAwuGsh+wnuk4BhJqKgdoRy0zDokYkJuSMk+weCA@mail.gmail.com>
	<CACzrW9BF1Mwntrxr2FqH234C9OPtfVjcgekBD3jriEYZFXNSmg@mail.gmail.com>
Message-ID: <CAP0svmoBVTzSUd_yXZF8Vz0azqssSU_nkDDJnyP6ZdX-s6yP3Q@mail.gmail.com>

:-) - In the case why is it even overridden?

Jim


On 15 January 2014 08:28, Stephen Colebourne <scolebourne at joda.org> wrote:

> Looks like a cut and paste error in the comment to me...
> Stephen
>
> On 15 January 2014 09:58, James Gough <jpgough at gmail.com> wrote:
> > Hi,
> >
> > This is a question about default methods in java.time in 1.8.0-ea. In
> > ChronoLocalDate interface the format method is a default method:
> >
> >     default String format(DateTimeFormatter formatter) {
> >         Objects.requireNonNull(formatter, "formatter");
> >         return formatter.format(this);
> >     }
> >
> > In LocalDate this default method is overridden with:
> >
> >     @Override  // override for Javadoc and performance
> >     public String format(DateTimeFormatter formatter) {
> >         Objects.requireNonNull(formatter, "formatter");
> >         return formatter.format(this);
> >     }
> >
> > What is the performance benefit of doing this? As it's the same code why
> > would we not just use the default method implementation?
> >
> > Regards,
> > Jim
> >
> >
> ------------------------------------------------------------------------------
> > 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
>

From ylt at letallec.org  Wed Jan 15 14:42:42 2014
From: ylt at letallec.org (Yann Le Tallec)
Date: Wed, 15 Jan 2014 22:42:42 +0000
Subject: [threeten-dev] Period javadoc
Message-ID: <CAOPu7EgAFcg98LAHEeoTsqP38i6fQiGjsnM_fKgP5_3mZ2KeDw@mail.gmail.com>

Hi all,
??
I have used java.time in a project recently and three persons in the
project made the same mistake: calling Period#getDays() to retrieve the
total number of days in a Period. Everybody had read the javadoc but still
produced code such as:

    LocalDate d1 = ...
    LocalDate d2 = ...
    int daysBetweenD1andD2 = Period.between(d1, d2).getDays(); //instead of
DAYS.between(d1, d2);

It seems the confusion came from the javadoc for the getDays method: "Gets
the amount of days of this period."

I don't know if it's too late for javadoc changes but I would suggest that
it should be made clearer that `getDays` returns the day component of the
period excluding the month and year components and is therefore different
from the total number of days that the period represents (which is a vague
concept since a Period does not have a start date). It may also be a good
idea to also link to ChronoUnit#between for the use case described above.

--------

Suggested wording for the class javadoc (this surely can be improved):

This class models a quantity or amount of time in terms of years, months
and days. See Duration<http://download.java.net/jdk8/docs/api/java/time/Duration.html>for
the time-based equivalent to this class. Because a Period does not
have
a start date, its month and year components can't be translated into a
number of days. To calculate the number of days elapsed between two dates,
the ChronoUnit.DAYS#between method should be used.

---------

The javadocs for getYear and getMonth already hint what the behaviour is,
but could maybe made clearer. For example getMonths states: "This means
that a period of "15 months" is different to a period of "1 year and 3
months""
It may be worth adding: "and getMonths() will return 15 and 3 respectively."

Similarly, the following wording could be added to the javadoc of getDays:

The days unit is not automatically normalized with the months and years
unit. This means that a period of "45 days" is different to a period of "1
month and 15 days" and getDays() will return 45 and 15 respectively.

Best,
Yann

From Roger.Riggs at Oracle.com  Fri Jan 17 13:42:36 2014
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 17 Jan 2014 16:42:36 -0500
Subject: [threeten-dev] JSR 310 Final Release Materials and Review
Message-ID: <52D9A3CC.7060709@Oracle.com>

Hi,

Please review the Final Release Specification 
<http://cr.openjdk.java.net/%7Erriggs/datetime-1_0-fr-spec.zip> (zip)[1] 
and materials.

Updates to the specification since PFD:

  * 8031103 <https://bugs.openjdk.java.net/browse/JDK-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


From anthony.vanelverdinghe at gmail.com  Sat Jan 18 05:26:35 2014
From: anthony.vanelverdinghe at gmail.com (Anthony Vanelverdinghe)
Date: Sat, 18 Jan 2014 14:26:35 +0100
Subject: [threeten-dev] JSR 310 Public Review Ballot results
Message-ID: <52DA810B.8060400@gmail.com>

After reading the Vote Log for the Public Review Ballot, I'm wondering 
if there's a public archive of the discussions between the JCP EC and 
the JSR EG? In particular, I'm interested in the feedback of the expert 
group to the points raised by Werner Keil. In an earlier post on this 
list, Roger Riggs said: "We will review the ballot comments and evaluate 
if changes are necessary.", so I'd like to know what the outcome of this 
review was.

Kind regards, Anthony


From scolebourne at joda.org  Sun Jan 19 03:53:16 2014
From: scolebourne at joda.org (Stephen Colebourne)
Date: Sun, 19 Jan 2014 11:53:16 +0000
Subject: [threeten-dev] JSR 310 Public Review Ballot results
In-Reply-To: <52DA810B.8060400@gmail.com>
References: <52DA810B.8060400@gmail.com>
Message-ID: <CACzrW9D7TSBPW8-iS2sc_XrOzgXAXjMWC6bQQRJi5AwttAo7=A@mail.gmail.com>

The specific comment from Werner is as follows:
"
Unfortunately this JSR has a significant number of issues.
The top 5:
- Lack of support for ISO-8601 (a standard last updated in late 2006,
long before the JSR started)
- Circular RI dependencies in the API/Spec (Duration is what one shall
consider part of RI, but it's used in the abstract API interface
TemporalUnit, effectively making independent 3rd party implementations
without using the RI impossible;-/)
- Giant footprint (larger than any single package of the JDK so far)
making this JSR irrelevant to a vast majority of the X-Billion devices
the IoT/M2M generations expects to see running Java ME Embedded in the
near future. Thus marginalizing the JSR as true cross-platform
solutions will never pick it up and stick to "good old
java.util.Date/Calendar".
- Redundancies, both concepts like ChronoField vs. ChronoUnit defining
things twice and Reinventing the JDK wheel, e.g. a DecimalStyle used
only here, which instead should have been better integrated with the
remaining JDK. All reasons for the excessive size.
- Violating design princples practiced across all of Java SE or EE,
especially use interfaces or abstract classes instead of concrete
types (everywhere from Collections, to Lambdas or JavaFX as well as
nearly every JSR these "Effecive Java" guidelines by Gosling, Bloch,
etc. are applied but in this JSR;-/)

>From a functional point of view, ICU4J (which not only helped improve
Java Date/Time in the past, but also Locale or other i18n related
parts of the JDK) offers not only the same features but exceeds it
both from the number of supported cultures, calendars and
chronologies, as well as business-critical ones like Holiday/workday
distinction. Where memory is not a problem, the 10-20MB of ICU4J won't
matter and provides features this JSR left out, while on small, memory
constrained devices neither ICU4J nor JSR 310 will matter. There
Date4J, see the switch of Google and others from JodaTime to Date4J
(http://www.date4j.net) an API doing the same with just 3 classes
where this JSR throws ~155(!) at Java has become the most popular
alternative. This JSR is "Too Big, too Late" for a Post-PC era I'm
afraid.

Having talked to other EC and JCP members and given a first response
by Spec Lead(s) showing little understanding of even the most gross
problem (IMHO that would be the Circular Dependency Antipattern,
making it even harder for Jigsaw and Java 9 than it already is to cope
with that) I must abstain.
"

My response:

JSR-310 has taken many years to complete to ensure that it is of the
appropriate size and style for the JDK. Date and time is a complex
domain that can be modelled in many different ways.

One way is to model it simply, such as with Date/Calender or Date4J.
These use few types to express the concepts. This results in small
size but weak safety - your application is responsible for checking
that the data you receive is actually a date, or a time for example.

The way adopted by JSR-310 (and Joda-Time) is more complex. It
provides separate types for each major concept - date, time,
date-time, plus types that distinguish between human/descriptive time
(LocalDate/LocalTime) vs time-line associated time
(ZonedDateTime/Instant). Each type that has been included serves a
specific purpose and has been debated many times over the years of the
JSR. They are also familiar to those using Joda-Time.

The core types of JSR-310 were always intended to be fully immutable
value types. To get the maximum benefit for developers, these types
need to be used as classes, not interfaces (as with interfaces you
cannot guarantee in your code whether the implementation really is
immutable). Once you choose to promote immutable classes as the
primary API, you find you also need an interoperability layer to allow
type conversion, something that is implemented using interfaces.

Unfortunately, Werner views the API backwards from what was designed
and what is intended. With JSR-310, the classes drive the API and the
interfaces are a secondary low-level detail. This is unlike most JSRs
which the JCP deal with, where the interfaces form the API and the
classes form the RI. Were JSR-310 a typical JSR (for the Java EE or
Java ME world) then Werner's criticism of "circular RI dependencies"
would be relevant. As that is not the intended design parallel, the
criticism is not especially relevant. JSR-310 is solely about
extending the JDK, and the JDK is closely controlled by Oracle, so
there will be no competing RI.

As it happens however, effort has gone in to make the interface level
as independent from the rest of the code as possible. The Duration
case mentioned by Werner is the best design for that case however, and
anything else would require additional interfaces and a weakening of
safety.

On size, the JSR consists of 5 packages. There are 18 public types in
the main package and 51 types in the other four packages (more
advanced concepts) - 69 public types in all. This is not IMO an
unreasonable number.

Some types have a large number of methods. This approach has been used
in Joda-Time and is very effective in providing readable code. To make
the methods manageable they are designed around naming conventions.
Specific method prefixes are used consistently, and the same method
names used across classes. As such, the number of methods is not IMO a
problem.

The unpacked bytecode size is 740kb which is 346kb when compressed by
zip (separate from the rest of the JDK). The java.util.stream and
java.util.function packages together added the same amount of bytecode
to the JDK - 738kb.

The JSR-310 project also caused the time-zone data of JDK 7 to be
replaced with a more efficient binary format for JDK 8 which saved
space. (From about 250kb to 40kb, see
http://mail.openjdk.java.net/pipermail/build-infra-dev/2013-February/003051.html
and http://openjdk.java.net/jeps/151).

If you need any further clarification, please ask.
thanks
Stephen





On 18 January 2014 13:26, Anthony Vanelverdinghe
<anthony.vanelverdinghe at gmail.com> wrote:
> After reading the Vote Log for the Public Review Ballot, I'm wondering if
> there's a public archive of the discussions between the JCP EC and the JSR
> EG? In particular, I'm interested in the feedback of the expert group to the
> points raised by Werner Keil. In an earlier post on this list, Roger Riggs
> said: "We will review the ballot comments and evaluate if changes are
> necessary.", so I'd like to know what the outcome of this review was.
>
> Kind regards, Anthony
>

From michel.graciano at gmail.com  Sat Jan 18 09:42:19 2014
From: michel.graciano at gmail.com (Michel Graciano)
Date: Sat, 18 Jan 2014 15:42:19 -0200
Subject: [threeten-dev] [threeten-develop] JSR 310 Final Release
	Materials and Review
In-Reply-To: <52D9A3CC.7060709@Oracle.com>
References: <52D9A3CC.7060709@Oracle.com>
Message-ID: <CAMGDm+anNxB-VcGSrBG9wsiLTYFUZ4geb1-5u-wkxDYdESNt=w@mail.gmail.com>

Roger,
looks like to me there is a typo for j.u.Date related to JSR 310.

Method:
http://download.java.net/jdk8/docs/api/java/util/Date.html#from-java.time.Instant-

Typo:
"The conversion will *trancate* any excess" looks to me here should be
'truncate'.

Hope it helps.


On Fri, Jan 17, 2014 at 7:42 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

>  Hi,
>
> Please review the Final Release Specification<http://cr.openjdk.java.net/%7Erriggs/datetime-1_0-fr-spec.zip>(zip)[1] and materials.
>
> Updates to the specification since PFD:
>
>    - 8031103 <https://bugs.openjdk.java.net/browse/JDK-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
>
>
>
> ------------------------------------------------------------------------------
> 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
>
>


-- 
Michel Graciano
http://www.michelgraciano.com.br
http://java.net/projects/genesis
http://java.net/projects/copypastehistory

From douglas.surber at oracle.com  Wed Jan 22 13:24:23 2014
From: douglas.surber at oracle.com (Douglas Surber)
Date: Wed, 22 Jan 2014 13:24:23 -0800
Subject: [threeten-dev] [threeten-develop] JSR 310 Final Release
 Materials and Review
In-Reply-To: <52D9A3CC.7060709@Oracle.com>
References: <52D9A3CC.7060709@Oracle.com>
Message-ID: <6.2.5.6.2.20140122130451.056e74c8@oracle.com>

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.

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.

As an aside, why 'MAX' rather than 'MAX_VALUE' as is used elsewhere?

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


From douglas.surber at oracle.com  Wed Jan 22 14:25:21 2014
From: douglas.surber at oracle.com (Douglas Surber)
Date: Wed, 22 Jan 2014 14:25:21 -0800
Subject: [threeten-dev] [threeten-develop] JSR 310 Final Release
 Materials and Review
In-Reply-To: <52D9A3CC.7060709@Oracle.com>
References: <52D9A3CC.7060709@Oracle.com>
Message-ID: <6.2.5.6.2.20140122142245.05686a68@oracle.com>

Duration.dividedBy(Duration) is missing. This is needed to determine 
the number of times a Duration occurs within another Duration, such 
has how many 12 minute periods in 4 hours. Stephen agreed that this 
was a good thing Jan 10, 2009.

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


From scolebourne at joda.org  Wed Jan 22 23:03:10 2014
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 23 Jan 2014 07:03:10 +0000
Subject: [threeten-dev] [threeten-develop] JSR 310 Final Release
	Materials and Review
In-Reply-To: <6.2.5.6.2.20140122130451.056e74c8@oracle.com>
References: <52D9A3CC.7060709@Oracle.com>
	<6.2.5.6.2.20140122130451.056e74c8@oracle.com>
Message-ID: <CACzrW9DpkwX9OC73Qoe03xfpXvwKMgHEVJGk7HaKqG_sUVD2Sw@mail.gmail.com>

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

From douglas.surber at oracle.com  Thu Jan 23 07:59:04 2014
From: douglas.surber at oracle.com (Douglas Surber)
Date: Thu, 23 Jan 2014 07:59:04 -0800
Subject: [threeten-dev] [threeten-develop] JSR 310 Final Release
 Materials and Review
In-Reply-To: <CACzrW9DpkwX9OC73Qoe03xfpXvwKMgHEVJGk7HaKqG_sUVD2Sw@mail.g
	mail.com>
References: <52D9A3CC.7060709@Oracle.com>
	<6.2.5.6.2.20140122130451.056e74c8@oracle.com>
	<CACzrW9DpkwX9OC73Qoe03xfpXvwKMgHEVJGk7HaKqG_sUVD2Sw@mail.gmail.com>
Message-ID: <6.2.5.6.2.20140123075704.051d4ec0@oracle.com>

At 11:03 PM 1/22/2014, Stephen Colebourne wrote:
> > 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.

java.time.Year uses MAX_VALUE and MIN_VALUE.

I think the distinction is too subtle for me. I would just type 
MAX_VALUE because that is the name of the constant that defines the 
largest element in the range, regardless of Object or primitive.

Douglas 


From scolebourne at joda.org  Thu Jan 23 08:18:20 2014
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 23 Jan 2014 16:18:20 +0000
Subject: [threeten-dev] [threeten-develop] JSR 310 Final Release
 Materials and Review
In-Reply-To: <6.2.5.6.2.20140123075704.051d4ec0@oracle.com>
References: <52D9A3CC.7060709@Oracle.com>
	<6.2.5.6.2.20140122130451.056e74c8@oracle.com>
	<CACzrW9DpkwX9OC73Qoe03xfpXvwKMgHEVJGk7HaKqG_sUVD2Sw@mail.gmail.com>
	<6.2.5.6.2.20140123075704.051d4ec0@oracle.com>
Message-ID: <CACzrW9Av+6EffXOo6ghycej0eUV=bTBDSnJpQZxnTHNRO3TkPQ@mail.gmail.com>

On 23 January 2014 15:59, Douglas Surber <douglas.surber at oracle.com> wrote:
> At 11:03 PM 1/22/2014, Stephen Colebourne wrote:
>>
>> > 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.
>
> java.time.Year uses MAX_VALUE and MIN_VALUE.

Because it returns int, not Year.

> I think the distinction is too subtle for me. I would just type MAX_VALUE
> because that is the name of the constant that defines the largest element in
> the range, regardless of Object or primitive.

I'm happy with the choice I made here. Its up to Roger/Sherman to
comment otherwise.
Stephen

From scolebourne at joda.org  Sun Jan 26 14:06:51 2014
From: scolebourne at joda.org (Stephen Colebourne)
Date: Sun, 26 Jan 2014 22:06:51 +0000
Subject: [threeten-dev] OMG date and time
Message-ID: <CACzrW9D8oKz_Sccw8zy3thB73YfdosvEBvb_MSadXxBrpi6UjQ@mail.gmail.com>

For those with the desire to read long standards documents, the Object
Management Group (OMG) is defining a vocabulary/ontology for date and
time:
http://www.omg.org/spec/DTV/1.0/

Stephen

From roger.riggs at oracle.com  Tue Jan 28 14:17:47 2014
From: roger.riggs at oracle.com (roger riggs)
Date: Tue, 28 Jan 2014 17:17:47 -0500
Subject: [threeten-dev] JSR 310 Final Release Materials and Review
In-Reply-To: <52D9A3CC.7060709@Oracle.com>
References: <52D9A3CC.7060709@Oracle.com>
Message-ID: <52E82C8B.8050708@oracle.com>

Hi,

Thanks for the comments on the Final Release version of the Date and 
Time specification.
There were all relatively minor and can be incorporated as 
clarifications into a future version of the specification. The 
implementation related issues can be fixed in an SE update release.
The SE 8 builds are being finalized and only showstopper issues can be 
fixed in the
initial SE 8 release.

The EG members will have seen the RI and TCK and have not identified any 
issues
with them.

I will be submitting the final materials to the PMO tomorrow.

Thanks, Roger



From Roger.Riggs at Oracle.com  Wed Jan 29 14:02:00 2014
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 29 Jan 2014 17:02:00 -0500
Subject: [threeten-dev] Update to JSR 310 FAB materials
Message-ID: <52E97A58.1070203@Oracle.com>

Hi,

A few of issues in SE necessitated regenerating the JSR 310 RI and TCK
(the same as the SE 8 RI and TCK).

The JSR 310 Final Release specification is unchanged.

The RI binary is available from: https://jdk8.java.net/java-se-8-ri/

The updated TCK binaries are in the same directories on 
java-partner.sun.com.

An update to the code coverage is attached with more detail about individual
packages and classes.  The 93%, I reported is for the java.time package but
the overall coverage number is lower (80%).

The code/spec coverage can and should be improved over time.

The submission to the PMO will be put off until next week to give it a 
bit of time to settle
and final documentation be produced.

fyi, Roger