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