[threeten-dev] Temporal API

[Stephen Colebourne]

Overall, I think the API is pretty sound. I've not had any huge reason
to doubt what we've got in the last few months.

The main area where there is a possible change is whether we should
have an "API" that is separate from all implementation code.

By this, I mean that the temporal interfaces - TemporalAccessor,
Temporal, TemporalUnit, TemporalField, TemporalAdjuster,
TemporalAmount and TemporalQuery - could form a small and isolated API
that is independent of all the implementation classes.

Right now, they are bound in as follows:
- TemporalField.resolve refers to ZoneId and Chronology. Could be
changes to TemporalAccessor.
- TemporalQuery and TemporalAdjuster refer to lots of classes in
static methods. Could remove the static methods on the interface and
revive the TemporalQueries and Temporal Adjusters as public classes.
- TemporalUnit refers to Duration.

The first two are easy to change and have very little impact. The
latter is much harder, as Duration is effectively the correct type to
use. It could be changed to TemporalAmount, but that makes it harder
to use. It could be change to be a long, but that limits the size of
the maximum TemporalUnit. Or it could be a long refering to another
unit - "one day = 24 hours".

The benefits of separating out the API as above are to allow future
evolution to use the API, but not the implementation. However, that
has never been a goal of the project. The lilkelihood is that there is
unlikely to be a replacement API in the JDK, and if there is it would
probably replace the whole of threeten, including the temporal
interfaces.

Given where we are, it seems unlikely that we will do the above, but
it should be mentioned/discussed.

I would say that the static methods on TemporalQuery and
TemporalAdjuster remain at the borders of good taste. There could be a
good case for reviving TemporalQueries and Temporal Adjusters as
public classes anyway.

In addition,

Stephen