Which if any would you support in JPA?
On Tue, May 2, 2017 at 4:20 PM, Steve Ebersole <steve_at_hibernate.org> wrote:
> 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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>
>>