users@jpa-spec.java.net

[jpa-spec users] Re: JPA_SPEC-63

From: Michael Nascimento <misterm_at_gmail.com>
Date: Thu, 4 May 2017 20:33:13 -0300

Exactly, which makes sense in terms of framework support, not end-user
visible API :-)

Basically, the principle is: frameworks/APIs can rely on interfaces if
necessary, but interface types should not be exposed for business users.

Regards,
Michael

On Thu, May 4, 2017 at 8:30 PM, <werner.keil_at_gmail.com> wrote:

> This would actually have been one of the underlying Abstract base
> Interfaces 😉
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> *From: *Michael Nascimento <misterm_at_gmail.com>
> *Sent: *Friday, May 5, 2017 01:24
> *To: *users_at_jpa-spec.java.net
> *Subject: *[jpa-spec users] Re: JPA_SPEC-63
>
>
>
> 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
>
>
>
>
>
>
>
>
>