Hi,
My proposal [1] was to support java.time.temporal.TemporalAccessor
implementations, but due mainly to limitations in ConstraintValidator, this
has been changed.
[1]
https://github.com/sjmisterm/beanvalidation.org/blob/3a31539ee84416241c00abb94555b2ff22fe7449/proposals/BVAL-496.adoc
Regards,
Michael
On Tue, May 2, 2017 at 11:02 AM, Steve Ebersole <steve_at_hibernate.org> wrote:
> 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
>>>>>>>
>>>>>>
>>>>>
>>>