[threeten-develop] JSR-310 face to face meeting with Oracle

[Stephen C. <sco...@jo...>]

On Tuesday and Wednesday this week, I met with Oracle (Roger Riggs,
Brian Goetz, Sherman Shen) to discuss how to proceed with JSR-310 to
achieve the JDK 8 target.

The two-day discussion was wide ranging and touched on every part of
the current API. As such, it is hard to describe every last detail of
what we talked about, but I'll attempt a summary.

Oracle has a desire to modularize the JDK, and as part of that, there
is a goal for the core JDK module to be small. It appears that a good
approach would be for the core parts of JSR-310 to be in the most core
JDK module, while other more advanced features would be in a secondary
JDK module. Users would have the choice to depend only on the core
(such as in the embedded space), or on the whole JDK (or other choices
in-between, chosen on a whole-module basis.)

To make this happen, it was necessary to discuss how the current
code-base could be split up. Bear in mind that the core module will
not be able to have any direct dependencies on the secondary module.

The working model for the split is as follows (ie, all subject to change):
Core
- Instant, Duration
- LocalDate,LocalTime, LocalDateTime
- OffsetDate,OffsetTime, OffsetDateTime
- MonthOfYear, DayOfWeek, AmPmOfDay
- ZonedDateTime
- ZoneId, ZoneOffset, new time zone package
- the old time zone code and new time zone code unified internally
- DateAdjuster
- Period
- Clock

Secondary
- Formatting (printing/parsing)
- Low-level framework (CalendricalRule, DateTimeRule, PeriodUnit, resolvers etc)
- DateTimeField(s)
- PeriodField(s)
- Global calendar systems - ChronologyDate<EthopicChronology>
- Historic Gregorian/Julian calendar system
- Year, YearMonth, MonthDay

Third-party jar (not in the JDK)
- UTC/TAI, TimeSource (all leapsecs and time-scale code)
- QuarterOfYear

As part of this split, it is apparent that formatting is not in the
core. Oracle expressed a strong desire to extend the capabilities of
the existing SimpleDateFormat and java.util.Formatter (printf) classes
to support the new 310 core types. Given this, the 310 formatting API
becomes the "better" formatting API, used if you care about immutable
formatters, or printing/parsing other calendar systems or more complex
use cases (and have access to the additional module).

A key part of the separation will be the removal from the core of
clutter, however I intend to make sure that this does not result in
the gutting of usability for more advanced use cases. As part of this,
some concepts will probably disappear entirely:
- CalendricalMatcher
- InstantProvider
- PeriodProvider

No doubt there will be other changes as the details are worked
through. For early adopters this is unfortunate, but I have to place
inclusion in the JDK at a higher priority than maintaining any kind of
compatability with the current source-base. That said, the main APIs
of the main classes is likely to stay roughly the same, even if in
another package.

The final JSR product will be fully integrated in the JDK, and as such
will only run on JDK 8. A reasonable backport to JDK 6/7 will be
needed, although the classes may be in a different package name in the
backport.

There was also discssion of various points of process. I expect to be
nominating Oracle as a co-spec lead in the near future, which should
aid the process of JDK integration. Expect to see more participation
from Roger, Sherman and other Oracle particpants as time progresses.

I'm happy to answer questions on any of the points above, or anything
else, and I suspect that those questions may be a better way of
teasing out how the discussion went than me writing a very long email
;-)

Stephen