[hibernate-dev] javax.money

[Steve Ebersole]

For sure we will support it in some fashion.  The discussion is simply
about the how

On Mon, Jan 4, 2016 at 1:04 AM Petar Tahchiev <paranoiabla at gmail.com> wrote:

> Any updates on this? What has been decided? Can we see some hibernate
> support for this JSR?
>
> 2015-12-26 19:13 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>
>> Correct.  And things are "possible in any number of ways".  Some are just
>> more right than others.  The fun is the fact that the question of which
>> which is more right can be different depending on your perspective and
>> that
>> is clearly the case here.
>>
>> >From the user's perspective the best solution is actually the least
>> attractive from the Hibernate development side of things... specifically
>> the best option for the user is for Hibernate to specify a compile-only
>> dependency (optional, provided, etc is irrelevant) and for Hibernate to
>> internally isolate itself from cases where javax.money is not available on
>> the classpath (reflection, etc).  Ultimately I think this is the direction
>> to go for this particular integration.
>>
>> On Wed, Dec 23, 2015 at 2:23 AM Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>
>> > It's software, so everything is *possible*. Question is whether we
>> > deem it acceptable for the user having to depend on another submodule
>> > or not. If you think that's ok, then go for it ;)
>> >
>> >
>> > 2015-12-22 23:09 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>> > > You mean in addition to Maven's own documentation?  Quote[1]:
>> > >
>> > > "Optional dependencies are used when it's not really possible (for
>> > whatever
>> > > reason) to split a project up into sub-modules. The idea is that some
>> of
>> > the
>> > > dependencies are only used for certain features in the project, and
>> will
>> > not
>> > > be needed if that feature isn't used. Ideally, such a feature would be
>> > split
>> > > into a sub-module that depended on the core functionality
>> project...this
>> > new
>> > > subproject would have only non-optional dependencies, since you'd need
>> > them
>> > > all if you decided to use the subproject's functionality."
>> > >
>> > > Beyond Maven's own documentation, simply google...
>> > >
>> > > [1]
>> > >
>> >
>> https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html
>> > >
>> > > On Tue, Dec 22, 2015 at 3:50 PM Gunnar Morling <gunnar at hibernate.org>
>> > wrote:
>> > >>
>> > >> To me, "optional" seems like the right thing for this case.
>> "Provided"
>> > >> (at least in the Maven world, I don't know whether Gradle has
>> > >> different semantics) suggests that this stuff is really to be
>> provided
>> > >> by the runtime; I interpret this as a mandatory requirement towards
>> > >> the environment (i.e. a Java EE container *has* to provide the
>> javax.*
>> > >> packages).
>> > >>
>> > >> Optional instead indicates that this stuff may be present at runtime
>> > >> or not. If it is present, some optional functionality will be
>> > >> available to the user, otherwise not. For the case of Money the user
>> > >> is depending on these types anyways - and thus required to expose
>> them
>> > >> on the runtime class path -  if he is wishing to work with these
>> types
>> > >> in his own code (or not otherwise). No need to analyse the dependency
>> > >> graph or whatsoever.
>> > >>
>> > >> As said we use that style in Hibernate Validator for optional
>> > >> constraint validators, and it works well, I can't remember of any
>> > >> related issue or complaint. I suppose it'd help if you could point to
>> > >> that resource describing potential issues with optional.
>> > >>
>> > >> 2015-12-22 20:31 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>> > >> > Well the Bitronix use-case is actually a perfect illustration of
>> why
>> > >> > optional/provided dependencies stink.  Nothing in the dependency
>> graph
>> > >> > indicates what you are expected to do here.  Bitronix users would
>> have
>> > >> > to
>> > >> > look at the documentation to understand this; and dependency
>> > >> > graph/analysis
>> > >> > tools would be completely at a loss.  And in Bitronix the
>> "decision"
>> > is
>> > >> > all
>> > >> > internal to Bitronix.  Here at least the argument is a little more
>> > >> > justified because we are really talking about looking to see if
>> > another
>> > >> > set
>> > >> > of classes (library) are present from the application's classloader
>> > >> > (since
>> > >> > the application would need to bind to Moneta, etc statically).
>> > >> >
>> > >> > 'optional' is flat out wrong; that is well documented elsewhere.  I
>> > can
>> > >> > be
>> > >> > persuaded to use 'provided' for something like this, as I already
>> > >> > stated.
>> > >> >
>> > >> >
>> > >> > On Tue, Dec 22, 2015 at 12:26 PM Vlad Mihalcea <
>> > mihalcea.vlad at gmail.com>
>> > >> > wrote:
>> > >> >
>> > >> >> That's how Bitronix Transaction Manager managed optional
>> dependencies
>> > >> >> as
>> > >> >> well.
>> > >> >> In its case cglib and javassist were optional dependencies and at
>> > >> >> runtime
>> > >> >> the framework decided whether to load one provider or the other.
>> > >> >>
>> > >> >> Vlad
>> > >> >>
>> > >> >> On Tue, Dec 22, 2015 at 8:01 PM, Sanne Grinovero <
>> > sanne at hibernate.org>
>> > >> >> wrote:
>> > >> >>
>> > >> >> > On 22 December 2015 at 17:34, Gunnar Morling <
>> gunnar at hibernate.org
>> > >
>> > >> >> wrote:
>> > >> >> > >> yes we could use an optional/provided dependency, but
>> > >> >> > >> that would not be "proper".
>> > >> >> > >
>> > >> >> > > That would actually be my preference; If the javax.money types
>> > are
>> > >> >> > > present, enable the required Types etc. otherwise not. It's a
>> > >> >> > > pattern
>> > >> >> > > we e.g. use in Validator, too, where we provide additional
>> > >> >> > > constraint
>> > >> >> > > validator types based on what's available in the runtime
>> > >> >> > > environment.
>> > >> >> >
>> > >> >> > +1
>> > >> >> >
>> > >> >> > > Why do you consider it as not proper?
>> > >> >> >
>> > >> >> > Same question for me. It might not be perfectly well defined in
>> > terms
>> > >> >> > of Maven dependencies, still I think the practical benefit for
>> > users
>> > >> >> > far outweights the cons.. if that's what you're referring to.
>> > >> >> >
>> > >> >> > Sanne
>> > >> >> >
>> > >> >> > >
>> > >> >> > >
>> > >> >> > > 2015-12-22 17:03 GMT+01:00 Steve Ebersole <
>> steve at hibernate.org>:
>> > >> >> > >> I had planned to support this JSR when I thought it would be
>> > part
>> > >> >> > >> of
>> > >> >> the
>> > >> >> > >> JDK.  But as it is, supporting this properly would mean a
>> whole
>> > >> >> > >> new
>> > >> >> > >> module/artifact just to add these few types + the dependency
>> > >> >> > >> (similar
>> > >> >> to
>> > >> >> > >> hibernate-java8).  I am not a fan of the fact that it would
>> > >> >> > >> require a
>> > >> >> > >> separate dependency; yes we could use an optional/provided
>> > >> >> > >> dependency,
>> > >> >> > but
>> > >> >> > >> that would not be "proper".
>> > >> >> > >>
>> > >> >> > >> I am interested in what others think.
>> > >> >> > >>
>> > >> >> > >> On Mon, Dec 21, 2015, 1:37 PM Petar Tahchiev
>> > >> >> > >> <paranoiabla at gmail.com>
>> > >> >> > wrote:
>> > >> >> > >>
>> > >> >> > >>> Hi guys,
>> > >> >> > >>>
>> > >> >> > >>> I've been playing lately with JSR 354 javax.money api (
>> > >> >> > >>> http://javamoney.java.net) and I was wondering if there's
>> any
>> > >> >> > >>> plans
>> > >> >> > for
>> > >> >> > >>> hibernate to support this.
>> > >> >> > >>>
>> > >> >> > >>> Thanks.
>> > >> >> > >>>
>> > >> >> > >>> --
>> > >> >> > >>> Regards, Petar!
>> > >> >> > >>> Karlovo, Bulgaria.
>> > >> >> > >>> ---
>> > >> >> > >>> Public PGP Key at:
>> > >> >> > >>>
>> > >> >> > >>>
>> > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
>> > >> >> > >>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550
>> C311
>> > >> >> > >>> 0611
>> > >> >> > >>> _______________________________________________
>> > >> >> > >>> hibernate-dev mailing list
>> > >> >> > >>> hibernate-dev at lists.jboss.org
>> > >> >> > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >> >> > >>>
>> > >> >> > >> _______________________________________________
>> > >> >> > >> hibernate-dev mailing list
>> > >> >> > >> hibernate-dev at lists.jboss.org
>> > >> >> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >> >> > > _______________________________________________
>> > >> >> > > hibernate-dev mailing list
>> > >> >> > > hibernate-dev at lists.jboss.org
>> > >> >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >> >> > _______________________________________________
>> > >> >> > hibernate-dev mailing list
>> > >> >> > hibernate-dev at lists.jboss.org
>> > >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >> >> >
>> > >> >> _______________________________________________
>> > >> >> hibernate-dev mailing list
>> > >> >> hibernate-dev at lists.jboss.org
>> > >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >> >>
>> > >> > _______________________________________________
>> > >> > hibernate-dev mailing list
>> > >> > hibernate-dev at lists.jboss.org
>> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>