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/res
>>>>>> ults?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/maste
>>>>>> r/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
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>