Steve,
Thanks for the quick response.
I am with you on JSR-310 being "broken" in that sense. It's not even a real
JSR (like JPA where the RI is not baked into the API, otherwise Hibernate
would be forced to use EclipseLink;-) as java.time.Temporal exposes that
concrete final class Duration instead of the abstract interface
TemporalAmount.
That completely polluted the API. Which is understandable based on what you
just quoted, but does not justify a JSR simply to be rubber-stamped by the
EC.
One Spec Lead (Roger from Oracle) tried to add an "embrional" API/Spec type
of construct while the other (Stephen) tried to prevent that whereever
possible. It should have been withdrawn as a JSR IMO and simply done as JEP
under OpenJDK for that reason;-(
Which is why I abstained on it in the EC:
https://jcp.org/en/jsr/results?id=5639
While the API is broken (hostile to any independent implementation) you can
stick to those abstract interfaces for most parts, see the "JSR 310 Bridge"
in the Java SE implementation of JSR 363:
https://github.com/unitsofmeasurement/uom-se/tree/master/src/main/java/tec/uom/se/quantity/time
Except for certain internal factories everything is passed, returned and
stored as TemporalUnit or TemporalAmount, so it is doable even though the
spec and ts driving lead argued and trid to develop against it;-)
Werner
On Tue, May 2, 2017 at 2:10 PM, Steve Ebersole <steve_at_hibernate.org> wrote:
> I am trying to understand why we would need these TemporalType additions.
> TemporalType really serves 2 purposes, imo:
>
> 1. indicates a precision for the temporal values in terms of DB storage
> 2. indicates the concrete `java.util.Date` subclass to use in the model
>
> If the application model defines the attribute as `java.util.Date` we need
> to know whether it represents a DATE, TIME or TIMESTAMP. Really this is a
> short-coming of the old (pre-8) temporal types in that the concrete
> temporal types are only available in `java.sql` flavors and most developers
> do not want to expose JDBC types in their model. Otherwise, if the
> application model defined attributes using the concrete `java.util.Date`
> sub-types then the TemporalType would not really be needed; we'd know based
> on the attribute type.
>
> In terms of support for Java 8 temporal values, the "precision" aspect
> does not change - a database can still only store temporal values in a
> discrete number of ways that already line up with the TemporalType values.
>
> Now... if the thought process is to allow the application model to define
> attributes of type `java.time.temporal.Temporal` then yes I can see the
> need to allow the application to indicate which specific concrete type to
> use. However, from the `java.time.temporal.Temporal` javadocs:
>
> <quote>
> This interface is a framework-level interface that should not be widely
> used in application code. Instead, applications should create and pass
> around instances of concrete types, such as LocalDate. There are many
> reasons for this, part of which is that implementations of this interface
> may be in calendar systems other than ISO. See ChronoLocalDate
> <https://docs.oracle.com/javase/8/docs/api/java/time/chrono/ChronoLocalDate.html>
> for a fuller discussion of the issues.
> </quote>
>
> So unless we plan on breaking that intended use and supporting models that
> expose attributes of type `java.time.temporal.Temporal` rather than the
> concrete types I just am not seeing why we need these added TemporalType
> values.
>
> Now IMO there is a discussion to be had in regards to temporal value
> storage and timezones, but that is another discussion.
>
>
> On Tue, May 2, 2017 at 6:43 AM Werner Keil <werner.keil_at_gmail.com> wrote:
>
>> I admit, it probably exceeds a simple MR, but since at least Bean
>> Validation 2 adds java.time support for Java EE 8 I wonder, if
>> https://java.net/jira/browse/JPA_SPEC-63 was addressable or not for EE 8?
>>
>> I am also aware of the gross incompatibility of e.g. java.sql.Time etc.
>> and the types in java.time all of which are final, so it does not look like
>> the underlying JDBC in 4.2 or beyond is able to support all of it, but
>> could e.g. TemporalType get further variations including "LOCAL_DATE_TIME",
>> "INSTANT" or whatever seems appropriate?
>>
>> Werner
>>
>