I am not saying that 310 is broken nor am I saying that it is not broken :)
I was really just describing the dual nature I see in JPA's TemporalType
and applying that to 310.
Whether we agree with something or not, its honestly irrelevant once it is
part of an accepted spec. Otherwise I would never have wasted my time
implementing a concept like entity graphs in Hibernate ;)
Really this all boils down to whether we want JPA to define support for 310
in a way that 310 says is not expected/intended. As we all know, using
something in the way it was not intended generally does not end well. So
here, do we want to support applications defining attributes as 310's
generalized `java.time.temporal.Temporal` contract, or whether we expect
(as 310 clearly states) that the application uses one of the specific
sub-types.
Personally I'd never use the generalized type, but that's just my personal
taste. Really what is more important is what we want to support for all
JPA users. And to me, when it comes to integration with other specs we
ought to honor the restrictions/expectations of that other spec in doing
so.
WRT TZ mapping, that is a separate yet IMO way more important consideration
to standardize.
On Tue, May 2, 2017 at 7:26 AM Werner Keil <werner.keil_at_gmail.com> wrote:
> 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
>>>
>>
>