Although it could have been done differently, I would also primarily try to
coordinate with JSR 367 and 380, both add 310 support to Java EE 8.
If they do it with the concrete classes which both make the impression,
then it's probably better to also do it in JPA.
We had a discussion in JSR 353 on Number vs. BigDecimal or BigInteger. Some
EG members suggested Number, others at Oracle said it should be the
concrete classes. So when Oracle went to offer JSON support for Java ME 8
Embedded, the Spec could not be used and was simply "forked" into
"com.oracle.mobile.json" or so where instead of BigDecimal and BigInteger
Number, Double or Long/Integer are used instead, otherwise it is an exact
copy of javax.json.
Again not sure, if it exceeds the scope of a pure MR, but even with Java EE
9 following 8 not too late after, it could be nice to streamline Java SE 8
support with those other JSRs.
On Tue, May 2, 2017 at 2:58 PM, Steve Ebersole <steve_at_hibernate.org> wrote:
> 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
>>>>
>>>
>>