Unfortunately this "compatibility" across specs is beyond the scope of just
JPA - it has to fall on shoulders of the overall EE spec.
I say unfortunately because we (Red Hat) have brought up to the EE EG quite
a few "collaboration concerns" between various individual EE specs without
any resolution. I don't know the right answer for that aspect; not much we
can do other than bring them up.
For me personally, I think that list looks just about perfect, with the
minor caveat that
neither TimeZone, SimpleTimeZone, Duration, Period, ZoneId nor ZoneOffset
are technically "temporal" values in the JPA TemporalType sense.
On Tue, May 2, 2017 at 9:10 AM Werner Keil <werner.keil_at_gmail.com> wrote:
> I suppose it depends on the TCK (in case of JSR 380 that's Open Source
> http://beanvalidation.org/2.0/tck/) how strict each JSR is, e.g. that
> every type in above list must be supported by a compatible implementation
> or a subset is enough...
>
>
>
> On Tue, May 2, 2017 at 4:07 PM, Werner Keil <werner.keil_at_gmail.com> wrote:
>
>> JSON-B is even a little more strict,
>>
>> Implementations MUST support binding of the following standard Java
>> date/time classes:
>> • java.util.Date
>> • java.util.Calendar
>> • java.util.GregorianCalendar
>> • java.util.TimeZone
>> • java.util.SimpleTimeZone
>> • java.time.Instant
>> • java.time.Duration
>> • java.time.Period
>> • java.time.LocalDate
>> • java.time.LocalTime
>> • java.time.LocalDateTime
>> • java.time.ZonedDateTime
>> • java.time.ZoneId
>> • java.time.ZoneOffset
>> • java.time.OffsetDateTime
>> • java.time.OffsetTime
>>
>>
>>
>> On Tue, May 2, 2017 at 4:03 PM, Werner Keil <werner.keil_at_gmail.com>
>> wrote:
>>
>>> From JSON-P/B presentations I did together with Dmitry (Spec Lead to
>>> both) I can say it should match BV 2.
>>>
>>> Due to the nature of the 310 types, it looks unlikely JDBC and
>>> java.sql.Date or Time could ever fully support them without a significant
>>> change of its entire structure (they cannot just extend Duration, but they
>>> could implement the abstract base types) but mapping allowed types for JPA
>>> Temporal, I assume that might work, but hard to say if it still counts as
>>> MR or not.
>>>
>>>
>>> On Tue, May 2, 2017 at 3:58 PM, Steve Ebersole <steve_at_hibernate.org>
>>> wrote:
>>>
>>>> I wholeheartedly agree that numeric type fragmentation in Java is a big
>>>> pain, but that is a different discussion.
>>>>
>>>> As far as 310, BV for sure does not support the
>>>> generalized `java.time.temporal.Temporal` interface; only (specific)
>>>> sub-types are portably supported. And honestly as I said earlier, I
>>>> personally think that is the correct decision for JPA as well.
>>>>
>>>> I have no idea what JSON-B says in regards to 310, so I cannot comment
>>>> on that.
>>>>
>>>>
>>>> On Tue, May 2, 2017 at 8:34 AM Werner Keil <werner.keil_at_gmail.com>
>>>> wrote:
>>>>
>>>>> 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
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>