Hi,

More cleanup of the factory methods and restored the generics
to enable the use case below.

Updated; please review:

javadoc:
     http://cr.openjdk.java.net/~rriggs/javadoc-chrono-generics-191/
webrev:
     http://cr.openjdk.java.net/~rriggs/webrev-chrono-generics-191/

If this is close, I'll merge with the other pending changes
and move the calendars to java.time.chrono.

Then we can put it out for review and only do fine tuning until the
push early next week.

inline...

On 2/4/2013 6:33 AM, Stephen Colebourne wrote:
On 4 February 2013 01:09, Roger Riggs <Roger.Riggs@oracle.com> wrote:

BTW, there are a few stray static methods in Chronology to support
date.atTime()
and creating ChronoZonedDateTime instances.  With static methods in
interfaces
is there a better place for them?
Remove ChronoDateImpl.atTime()  (pointless override of ChronoLocalDate)
Make Chronology.dateTime(ChronoLocalDate<R> date, LocalTime time)
package scoped.
Add Javadoc (useful for those reading code rather than HTML Javadoc)
     * <p>
     * This method is called from {@link ChronoLocalDate#atTime(LocalTime)}.
     * Application code, and implementations of this class, should use
     * {@code atTime} to create a {@code ChronoLocalDateTime}.

There might also be a case for removing getEra() from ChronoLocalDate
as it adds less value now (it could still be on JapaneseDate and
others where it matters).
The era is still needed to be able to pass to Chronology to create dates.
Even the package private method seemed unnecessary.
The implemenetation of ChronoLocalDate.atTime can call the ChronoLocalDateTimeImpl directly. Going through the chronology isn't
does add any value.

Or getEra() could be replaced by Era.from() static method. But its
more useful to chrono-level (c) users as is.

On 4 February 2013 04:27, Roger Riggs <Roger.Riggs@oracle.com> wrote:
Cleaned up the methods on the Chrono and calendar types and updated the
javadoc.

But the generics on ChronoLocalDate will need to be restored.
Without  them it is not possible to write a library than can return
the same type of date passed in.    Something as simple as:

<D extends ChronoLocalDate> D next(D date) {
!    D next = date.plus(2, DAYS);
    return next;
}

fails because the type of date.plus is always ChronoLocalDate.
I'm OK with that if you prefer it that way. Removing generics from
Chronlogy/Era and making the date clases public is a net win I think.
yes,

I reviewed the Javadoc.
The main issue is that the of() factory methods on the 4 date classes
are inconsistent. The full set of methods would be
1) now()
2) now(ZoneId)
3) now(Clock)
4) from(TemporalAccessor)
5) of(y,m,d)
6) of(e,y,m,d)
7) ofYearDay(y,d)
8) ofYearDay(e,y,d)
9) parse(CharSeq)
10) parse(CharSeq, DTFormatter)

I think that from the perspective of (b) user, they definitely want
(4) and (5) and probably (1) (2) and (3).

(6), (7) and (8) seem like ones they could live without, except on
JapaneseDate where (6) would be needed.
ok, I implemented 1, 2,3,4, 5 and 6 for Japanese.

The parse methods (9) and (10) would also be desirable, but could
probably be lived without so long as (4) is present to use as a method
reference.

The implementations of these methods could delegate to the matching
chronlogy for simplicity.
Yes, took the simple implementation path for now.

Roger