[hibernate-dev] javax.money

[Vlad Mihalcea]

That's true. The dependency graph alone doesn't tell the full story so the
user needs to read the docs to understand the magic binding. In fact, it
was not that bad because the default mechanism was using the JDK proxies,
so the cglib/javassist was just as a performance optimization.

I see your point, as that's what I used in FlexyPool too:
https://github.com/vladmihalcea/flexy-pool
Each connection pool or even JDK 7 specific API are moved to separate
packages, but the end-user still needs to read the docs to know which of
those dependencies to include.

I'm not aware of the dangers of optional dependencies. If you recall such
an article/discussion, could you add it to this discussion.

Thanks,
Vlad

On Tue, Dec 22, 2015 at 9:31 PM, Steve Ebersole <steve at hibernate.org> wrote:

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