Re: [threeten-develop] [threeten:discussion] True API with Interfaces?

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

On 19 February 2013 20:16, "Jörg Hohwiller" <hoh...@us...> wrote:
> First of all thanks for putting your energy into this JSR. We all suffered
> with java.util.Date and Calendar and what you created is very promising. I
> cross fingers that it will make it into Java8.
>
> However, what I am missing is a true API. In Java the most important and
> successful JSRs have standardized APIs such as JPA, CDI, etc.
> JSRs that have not earned the right success have e.g. been the logging stuff
> that purely focused on the implementation and that is also the problem of
> java.util.Date and Calendar. The API was "designed" by the poor guys that
> hat to implement all these complicated stuff. If those days they had defined
> proper interfaces for date and time that are part of every JRE we could all
> happily use jodetime together with hibernate and all other frameworks.
>
> Some time ago when I feelt that it took for this JSR to make its way, I
> quickly wrote some API for date and time (I dont want to actually release
> this and would love to see such API in JSR 310 - not my API, yours is fine
> but with interfaces - your enums are already fine). It is not really great
> but please have a look:
> http://m-m-m.sourceforge.net/apidocs/net/sf/mmm/util/date/api/package-summary.html
>
> Why dont you have such interfaces? Are you aware that Java is really huge
> and there are islands like GWT where java code gets compiled to java-script
> and there your work might not be available as you implementation is tight
> together with implementation details such as resources read from the
> classpath, etc.
>
> Please believe me what we need at most is an API that is accepted by
> everybody. Your current API is fine from the signature point of view but
> please consider creating interfaces.

The first point to note is that the "JSR" part of JSR-310 is not
comparable to those such as JPA or other JavaEE specs. JSR-310 is
simply a mechanism/process to get code into the JDK, nothing more.

Secondly, interfaces are not always the appropriate tool for design. A
method receiving an interface knows nothing about the implementing
class, thus it cannot rely on it being thread-safe or immutable, facts
which are becoming increasingly important. The date/time classes are
also "value types", similar to Integer, Character and String. All of
these are final and immutable classes.

However, there is a role for interfaces in interoperability. Thats why
JSR-310 provides the "temporal" package, where the interfaces
"TemporalAccessor", "Temporal" and "TemporalAmount" can be implemented
outside the JDK, and yet easily converted to JDK classes and used in
formatting/parsing. Thus, your library, or Joda-Time, could implement
the temporal interfaces.

thanks
Stephen