[threeten-dev] JSR 310 Public Review Ballot results

[Stephen Colebourne]

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
>