users@jpa-spec.java.net

[jpa-spec users] Re: JPA_SPEC-63

From: Steve Ebersole <steve_at_hibernate.org>
Date: Tue, 02 May 2017 17:40:53 +0000

I'd support all of them. Just pointing out that imo not all of them are
"TemporalTypes"

On Tue, May 2, 2017, 9:24 AM Werner Keil <werner.keil_at_gmail.com> wrote:

> 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
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>