For what it is worth, here is the complete list of specific types supported
for BV[1]:
* Supported types are:
* <ul>
* <li>{_at_code java.util.Date}</li>
* <li>{_at_code java.util.Calendar}</li>
* <li>{_at_code java.time.Instant}</li>
* <li>{_at_code java.time.LocalDate}</li>
* <li>{_at_code java.time.LocalDateTime}</li>
* <li>{_at_code java.time.LocalTime}</li>
* <li>{_at_code java.time.MonthDay}</li>
* <li>{_at_code java.time.OffsetDateTime}</li>
* <li>{_at_code java.time.OffsetTime}</li>
* <li>{_at_code java.time.Year}</li>
* <li>{_at_code java.time.YearMonth}</li>
* <li>{_at_code java.time.ZonedDateTime}</li>
* <li>{_at_code java.time.chrono.HijrahDate}</li>
* <li>{_at_code java.time.chrono.JapaneseDate}</li>
* <li>{_at_code java.time.chrono.MinguoDate}</li>
* <li>{_at_code java.time.chrono.ThaiBuddhistDate}</li>
* </ul>
[1]
http://beanvalidation.org/2.0/spec/2.0.0.beta1/ (see *Example 124.
@Past constraint* and *Example 125. @Future constraint*)
On Tue, May 2, 2017 at 8:58 AM 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
>>>>>>
>>>>>
>>>>
>>