[beanutils2] Assertions class vs. lang Validate

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[beanutils2] Assertions class vs. lang Validate

André Diermann
Hello,

I noticed that the majority (all?) functionality of the Assertions class is
already covert by commons-lang Validate [1].

For instance Assertions.checkNotNull() is an equivalent to
Validate.notNull().

Is there a reason for this?

Regards,
André

[1]
http://commons.apache.org/proper/commons-lang/javadocs/api-release/index.html
Reply | Threaded
Open this post in threaded view
|

Re: [beanutils2] Assertions class vs. lang Validate

Simone Tripodi-2
Salut André,

to avoid to depend to an external lib just to get benefit of 3 methods :)

Best,
-Simo

http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi


On Sat, Mar 1, 2014 at 5:27 PM, André Diermann <[hidden email]>wrote:

> Hello,
>
> I noticed that the majority (all?) functionality of the Assertions class is
> already covert by commons-lang Validate [1].
>
> For instance Assertions.checkNotNull() is an equivalent to
> Validate.notNull().
>
> Is there a reason for this?
>
> Regards,
> André
>
> [1]
>
> http://commons.apache.org/proper/commons-lang/javadocs/api-release/index.html
>
Reply | Threaded
Open this post in threaded view
|

Re: [beanutils2] Assertions class vs. lang Validate

garydgregory
In reply to this post by André Diermann
My preference would be for components like [io] and [lang] to be reused
from other components as a dependency in order to avoid this kind of
duplication.

Gary


On Sat, Mar 1, 2014 at 11:27 AM, André Diermann <[hidden email]>wrote:

> Hello,
>
> I noticed that the majority (all?) functionality of the Assertions class is
> already covert by commons-lang Validate [1].
>
> For instance Assertions.checkNotNull() is an equivalent to
> Validate.notNull().
>
> Is there a reason for this?
>
> Regards,
> André
>
> [1]
>
> http://commons.apache.org/proper/commons-lang/javadocs/api-release/index.html
>



--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [beanutils2] Assertions class vs. lang Validate

garydgregory
I should clarify that I see components like [io] and [lang] as lower level
than [beanutils] for example.

Gary


On Sat, Mar 1, 2014 at 11:32 AM, Gary Gregory <[hidden email]>wrote:

> My preference would be for components like [io] and [lang] to be reused
> from other components as a dependency in order to avoid this kind of
> duplication.
>
> Gary
>
>
> On Sat, Mar 1, 2014 at 11:27 AM, André Diermann <[hidden email]>wrote:
>
>> Hello,
>>
>> I noticed that the majority (all?) functionality of the Assertions class
>> is
>> already covert by commons-lang Validate [1].
>>
>> For instance Assertions.checkNotNull() is an equivalent to
>> Validate.notNull().
>>
>> Is there a reason for this?
>>
>> Regards,
>> André
>>
>> [1]
>>
>> http://commons.apache.org/proper/commons-lang/javadocs/api-release/index.html
>>
>
>
>
> --
> E-Mail: [hidden email] | [hidden email]
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [beanutils2] Assertions class vs. lang Validate

André Diermann
In reply to this post by garydgregory
Simon, that makes totally sense to me :) ..that's why I also often struggle
to use StringUtils for instance... but it starts with only one method and
after some time I find myself in having copied a lot of methods.

That's why I like Gary's idea too. Regarding BU2, MethodUtil and TypeUtil
are also subsets from their lang pendants. So, when extending BU2 more and
more to BU's feature set, there might be even more copied methods...

But I am not so deep in BU2's component architecture like you guys, so to
keep it lightweight is fine for more :) I was only wondering why it was not
reused.

Thank you.


2014-03-01 17:32 GMT+01:00 Gary Gregory <[hidden email]>:

> My preference would be for components like [io] and [lang] to be reused
> from other components as a dependency in order to avoid this kind of
> duplication.
>
> Gary
>
>
> On Sat, Mar 1, 2014 at 11:27 AM, André Diermann <[hidden email]
> >wrote:
>
> > Hello,
> >
> > I noticed that the majority (all?) functionality of the Assertions class
> is
> > already covert by commons-lang Validate [1].
> >
> > For instance Assertions.checkNotNull() is an equivalent to
> > Validate.notNull().
> >
> > Is there a reason for this?
> >
> > Regards,
> > André
> >
> > [1]
> >
> >
> http://commons.apache.org/proper/commons-lang/javadocs/api-release/index.html
> >
>
>
>
> --
> E-Mail: [hidden email] | [hidden email]
> Java Persistence with Hibernate, Second Edition<
> http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
Reply | Threaded
Open this post in threaded view
|

Re: [beanutils2] Assertions class vs. lang Validate

Benedikt Ritter-4
I don't like the idea of creating some kind of component hierarchy, where
components higher up may depend on lower levels libs. This should be
decided for every individual case.

In the case of BU2 I'd say it's better to change the language level
requirement to 1.7. We could use Objects.notNull.
Other benefits include the new ReflectiveOperationException root exception
[1] which was introduced in Java 7 and the multi catch blocks. This would
make the exception handling and wrapping code much more clearer.

Benedikt

[1]
http://docs.oracle.com/javase/7/docs/api/java/lang/ReflectiveOperationException.html


2014-03-01 17:50 GMT+01:00 André Diermann <[hidden email]>:

> Simon, that makes totally sense to me :) ..that's why I also often struggle
> to use StringUtils for instance... but it starts with only one method and
> after some time I find myself in having copied a lot of methods.
>
> That's why I like Gary's idea too. Regarding BU2, MethodUtil and TypeUtil
> are also subsets from their lang pendants. So, when extending BU2 more and
> more to BU's feature set, there might be even more copied methods...
>
> But I am not so deep in BU2's component architecture like you guys, so to
> keep it lightweight is fine for more :) I was only wondering why it was not
> reused.
>
> Thank you.
>
>
> 2014-03-01 17:32 GMT+01:00 Gary Gregory <[hidden email]>:
>
> > My preference would be for components like [io] and [lang] to be reused
> > from other components as a dependency in order to avoid this kind of
> > duplication.
> >
> > Gary
> >
> >
> > On Sat, Mar 1, 2014 at 11:27 AM, André Diermann <
> [hidden email]
> > >wrote:
> >
> > > Hello,
> > >
> > > I noticed that the majority (all?) functionality of the Assertions
> class
> > is
> > > already covert by commons-lang Validate [1].
> > >
> > > For instance Assertions.checkNotNull() is an equivalent to
> > > Validate.notNull().
> > >
> > > Is there a reason for this?
> > >
> > > Regards,
> > > André
> > >
> > > [1]
> > >
> > >
> >
> http://commons.apache.org/proper/commons-lang/javadocs/api-release/index.html
> > >
> >
> >
> >
> > --
> > E-Mail: [hidden email] | [hidden email]
> > Java Persistence with Hibernate, Second Edition<
> > http://www.manning.com/bauer3/>
> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > Spring Batch in Action <http://www.manning.com/templier/>
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
> >
>



--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Reply | Threaded
Open this post in threaded view
|

Re: [beanutils2] Assertions class vs. lang Validate

garydgregory
On Sat, Mar 1, 2014 at 12:33 PM, Benedikt Ritter <[hidden email]> wrote:

> I don't like the idea of creating some kind of component hierarchy, where
> components higher up may depend on lower levels libs. This should be
> decided for every individual case.
>
> In the case of BU2 I'd say it's better to change the language level
> requirement to 1.7. We could use Objects.notNull.
> Other benefits include the new ReflectiveOperationException root exception
> [1] which was introduced in Java 7 and the multi catch blocks. This would
> make the exception handling and wrapping code much more clearer.
>

Go for it! :)

Gary


>
> Benedikt
>
> [1]
>
> http://docs.oracle.com/javase/7/docs/api/java/lang/ReflectiveOperationException.html
>
>
> 2014-03-01 17:50 GMT+01:00 André Diermann <[hidden email]>:
>
> > Simon, that makes totally sense to me :) ..that's why I also often
> struggle
> > to use StringUtils for instance... but it starts with only one method and
> > after some time I find myself in having copied a lot of methods.
> >
> > That's why I like Gary's idea too. Regarding BU2, MethodUtil and TypeUtil
> > are also subsets from their lang pendants. So, when extending BU2 more
> and
> > more to BU's feature set, there might be even more copied methods...
> >
> > But I am not so deep in BU2's component architecture like you guys, so to
> > keep it lightweight is fine for more :) I was only wondering why it was
> not
> > reused.
> >
> > Thank you.
> >
> >
> > 2014-03-01 17:32 GMT+01:00 Gary Gregory <[hidden email]>:
> >
> > > My preference would be for components like [io] and [lang] to be reused
> > > from other components as a dependency in order to avoid this kind of
> > > duplication.
> > >
> > > Gary
> > >
> > >
> > > On Sat, Mar 1, 2014 at 11:27 AM, André Diermann <
> > [hidden email]
> > > >wrote:
> > >
> > > > Hello,
> > > >
> > > > I noticed that the majority (all?) functionality of the Assertions
> > class
> > > is
> > > > already covert by commons-lang Validate [1].
> > > >
> > > > For instance Assertions.checkNotNull() is an equivalent to
> > > > Validate.notNull().
> > > >
> > > > Is there a reason for this?
> > > >
> > > > Regards,
> > > > André
> > > >
> > > > [1]
> > > >
> > > >
> > >
> >
> http://commons.apache.org/proper/commons-lang/javadocs/api-release/index.html
> > > >
> > >
> > >
> > >
> > > --
> > > E-Mail: [hidden email] | [hidden email]
> > > Java Persistence with Hibernate, Second Edition<
> > > http://www.manning.com/bauer3/>
> > > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > > Spring Batch in Action <http://www.manning.com/templier/>
> > > Blog: http://garygregory.wordpress.com
> > > Home: http://garygregory.com/
> > > Tweet! http://twitter.com/GaryGregory
> > >
> >
>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>



--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [beanutils2] Assertions class vs. lang Validate

André Diermann
In reply to this post by Benedikt Ritter-4
But will upgrading to 1.7 will solve the core "issue", that some features
(in detail: Assertions, MethodUitl and TypeUtil) are copied subsets of
already implemented features in other Commons projects?

From what I can see commons.lang3 is already referenced by BU2 (although
it's currently only used by TestBean).




2014-03-01 18:33 GMT+01:00 Benedikt Ritter <[hidden email]>:

> I don't like the idea of creating some kind of component hierarchy, where
> components higher up may depend on lower levels libs. This should be
> decided for every individual case.
>
> In the case of BU2 I'd say it's better to change the language level
> requirement to 1.7. We could use Objects.notNull.
> Other benefits include the new ReflectiveOperationException root exception
> [1] which was introduced in Java 7 and the multi catch blocks. This would
> make the exception handling and wrapping code much more clearer.
>
> Benedikt
>
> [1]
>
> http://docs.oracle.com/javase/7/docs/api/java/lang/ReflectiveOperationException.html
>
>
> 2014-03-01 17:50 GMT+01:00 André Diermann <[hidden email]>:
>
> > Simon, that makes totally sense to me :) ..that's why I also often
> struggle
> > to use StringUtils for instance... but it starts with only one method and
> > after some time I find myself in having copied a lot of methods.
> >
> > That's why I like Gary's idea too. Regarding BU2, MethodUtil and TypeUtil
> > are also subsets from their lang pendants. So, when extending BU2 more
> and
> > more to BU's feature set, there might be even more copied methods...
> >
> > But I am not so deep in BU2's component architecture like you guys, so to
> > keep it lightweight is fine for more :) I was only wondering why it was
> not
> > reused.
> >
> > Thank you.
> >
> >
> > 2014-03-01 17:32 GMT+01:00 Gary Gregory <[hidden email]>:
> >
> > > My preference would be for components like [io] and [lang] to be reused
> > > from other components as a dependency in order to avoid this kind of
> > > duplication.
> > >
> > > Gary
> > >
> > >
> > > On Sat, Mar 1, 2014 at 11:27 AM, André Diermann <
> > [hidden email]
> > > >wrote:
> > >
> > > > Hello,
> > > >
> > > > I noticed that the majority (all?) functionality of the Assertions
> > class
> > > is
> > > > already covert by commons-lang Validate [1].
> > > >
> > > > For instance Assertions.checkNotNull() is an equivalent to
> > > > Validate.notNull().
> > > >
> > > > Is there a reason for this?
> > > >
> > > > Regards,
> > > > André
> > > >
> > > > [1]
> > > >
> > > >
> > >
> >
> http://commons.apache.org/proper/commons-lang/javadocs/api-release/index.html
> > > >
> > >
> > >
> > >
> > > --
> > > E-Mail: [hidden email] | [hidden email]
> > > Java Persistence with Hibernate, Second Edition<
> > > http://www.manning.com/bauer3/>
> > > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > > Spring Batch in Action <http://www.manning.com/templier/>
> > > Blog: http://garygregory.wordpress.com
> > > Home: http://garygregory.com/
> > > Tweet! http://twitter.com/GaryGregory
> > >
> >
>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>
Reply | Threaded
Open this post in threaded view
|

Re: [beanutils2] Assertions class vs. lang Validate

Paul Benedict
I recommend copying the source of the Commons Lang classes you use and
maintain it privately. It is only two classes, right?
On Mar 1, 2014 12:51 PM, "André Diermann" <[hidden email]> wrote:

> But will upgrading to 1.7 will solve the core "issue", that some features
> (in detail: Assertions, MethodUitl and TypeUtil) are copied subsets of
> already implemented features in other Commons projects?
>
> From what I can see commons.lang3 is already referenced by BU2 (although
> it's currently only used by TestBean).
>
>
>
>
> 2014-03-01 18:33 GMT+01:00 Benedikt Ritter <[hidden email]>:
>
> > I don't like the idea of creating some kind of component hierarchy, where
> > components higher up may depend on lower levels libs. This should be
> > decided for every individual case.
> >
> > In the case of BU2 I'd say it's better to change the language level
> > requirement to 1.7. We could use Objects.notNull.
> > Other benefits include the new ReflectiveOperationException root
> exception
> > [1] which was introduced in Java 7 and the multi catch blocks. This would
> > make the exception handling and wrapping code much more clearer.
> >
> > Benedikt
> >
> > [1]
> >
> >
> http://docs.oracle.com/javase/7/docs/api/java/lang/ReflectiveOperationException.html
> >
> >
> > 2014-03-01 17:50 GMT+01:00 André Diermann <[hidden email]>:
> >
> > > Simon, that makes totally sense to me :) ..that's why I also often
> > struggle
> > > to use StringUtils for instance... but it starts with only one method
> and
> > > after some time I find myself in having copied a lot of methods.
> > >
> > > That's why I like Gary's idea too. Regarding BU2, MethodUtil and
> TypeUtil
> > > are also subsets from their lang pendants. So, when extending BU2 more
> > and
> > > more to BU's feature set, there might be even more copied methods...
> > >
> > > But I am not so deep in BU2's component architecture like you guys, so
> to
> > > keep it lightweight is fine for more :) I was only wondering why it was
> > not
> > > reused.
> > >
> > > Thank you.
> > >
> > >
> > > 2014-03-01 17:32 GMT+01:00 Gary Gregory <[hidden email]>:
> > >
> > > > My preference would be for components like [io] and [lang] to be
> reused
> > > > from other components as a dependency in order to avoid this kind of
> > > > duplication.
> > > >
> > > > Gary
> > > >
> > > >
> > > > On Sat, Mar 1, 2014 at 11:27 AM, André Diermann <
> > > [hidden email]
> > > > >wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > I noticed that the majority (all?) functionality of the Assertions
> > > class
> > > > is
> > > > > already covert by commons-lang Validate [1].
> > > > >
> > > > > For instance Assertions.checkNotNull() is an equivalent to
> > > > > Validate.notNull().
> > > > >
> > > > > Is there a reason for this?
> > > > >
> > > > > Regards,
> > > > > André
> > > > >
> > > > > [1]
> > > > >
> > > > >
> > > >
> > >
> >
> http://commons.apache.org/proper/commons-lang/javadocs/api-release/index.html
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > E-Mail: [hidden email] | [hidden email]
> > > > Java Persistence with Hibernate, Second Edition<
> > > > http://www.manning.com/bauer3/>
> > > > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > > > Spring Batch in Action <http://www.manning.com/templier/>
> > > > Blog: http://garygregory.wordpress.com
> > > > Home: http://garygregory.com/
> > > > Tweet! http://twitter.com/GaryGregory
> > > >
> > >
> >
> >
> >
> > --
> > http://people.apache.org/~britter/
> > http://www.systemoutprintln.de/
> > http://twitter.com/BenediktRitter
> > http://github.com/britter
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [beanutils2] Assertions class vs. lang Validate

Matt Benson-2
And just to add fuel to the fire and ensure every possible opinion is
represented, I agree with Gary, but would support shading after the fact to
reduce the dependency requirements.

Matt
On Mar 1, 2014 1:38 PM, "Paul Benedict" <[hidden email]> wrote:

> I recommend copying the source of the Commons Lang classes you use and
> maintain it privately. It is only two classes, right?
> On Mar 1, 2014 12:51 PM, "André Diermann" <[hidden email]>
> wrote:
>
> > But will upgrading to 1.7 will solve the core "issue", that some features
> > (in detail: Assertions, MethodUitl and TypeUtil) are copied subsets of
> > already implemented features in other Commons projects?
> >
> > From what I can see commons.lang3 is already referenced by BU2 (although
> > it's currently only used by TestBean).
> >
> >
> >
> >
> > 2014-03-01 18:33 GMT+01:00 Benedikt Ritter <[hidden email]>:
> >
> > > I don't like the idea of creating some kind of component hierarchy,
> where
> > > components higher up may depend on lower levels libs. This should be
> > > decided for every individual case.
> > >
> > > In the case of BU2 I'd say it's better to change the language level
> > > requirement to 1.7. We could use Objects.notNull.
> > > Other benefits include the new ReflectiveOperationException root
> > exception
> > > [1] which was introduced in Java 7 and the multi catch blocks. This
> would
> > > make the exception handling and wrapping code much more clearer.
> > >
> > > Benedikt
> > >
> > > [1]
> > >
> > >
> >
> http://docs.oracle.com/javase/7/docs/api/java/lang/ReflectiveOperationException.html
> > >
> > >
> > > 2014-03-01 17:50 GMT+01:00 André Diermann <[hidden email]>:
> > >
> > > > Simon, that makes totally sense to me :) ..that's why I also often
> > > struggle
> > > > to use StringUtils for instance... but it starts with only one method
> > and
> > > > after some time I find myself in having copied a lot of methods.
> > > >
> > > > That's why I like Gary's idea too. Regarding BU2, MethodUtil and
> > TypeUtil
> > > > are also subsets from their lang pendants. So, when extending BU2
> more
> > > and
> > > > more to BU's feature set, there might be even more copied methods...
> > > >
> > > > But I am not so deep in BU2's component architecture like you guys,
> so
> > to
> > > > keep it lightweight is fine for more :) I was only wondering why it
> was
> > > not
> > > > reused.
> > > >
> > > > Thank you.
> > > >
> > > >
> > > > 2014-03-01 17:32 GMT+01:00 Gary Gregory <[hidden email]>:
> > > >
> > > > > My preference would be for components like [io] and [lang] to be
> > reused
> > > > > from other components as a dependency in order to avoid this kind
> of
> > > > > duplication.
> > > > >
> > > > > Gary
> > > > >
> > > > >
> > > > > On Sat, Mar 1, 2014 at 11:27 AM, André Diermann <
> > > > [hidden email]
> > > > > >wrote:
> > > > >
> > > > > > Hello,
> > > > > >
> > > > > > I noticed that the majority (all?) functionality of the
> Assertions
> > > > class
> > > > > is
> > > > > > already covert by commons-lang Validate [1].
> > > > > >
> > > > > > For instance Assertions.checkNotNull() is an equivalent to
> > > > > > Validate.notNull().
> > > > > >
> > > > > > Is there a reason for this?
> > > > > >
> > > > > > Regards,
> > > > > > André
> > > > > >
> > > > > > [1]
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://commons.apache.org/proper/commons-lang/javadocs/api-release/index.html
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > E-Mail: [hidden email] | [hidden email]
> > > > > Java Persistence with Hibernate, Second Edition<
> > > > > http://www.manning.com/bauer3/>
> > > > > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > > > > Spring Batch in Action <http://www.manning.com/templier/>
> > > > > Blog: http://garygregory.wordpress.com
> > > > > Home: http://garygregory.com/
> > > > > Tweet! http://twitter.com/GaryGregory
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > http://people.apache.org/~britter/
> > > http://www.systemoutprintln.de/
> > > http://twitter.com/BenediktRitter
> > > http://github.com/britter
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [beanutils2] Assertions class vs. lang Validate

Adrian Crum-3
In reply to this post by Benedikt Ritter-4
On 3/1/2014 9:33 AM, Benedikt Ritter wrote:
> I don't like the idea of creating some kind of component hierarchy, where
> components higher up may depend on lower levels libs. This should be
> decided for every individual case.

I agree. If I just want some basic low-level library, I don't want it to
have a multitude of silly dependencies.

One of the main problems with this community is the
top-down-one-size-fits-all mentality. It just makes things a lot harder
than they should be from a user's/developer's perspective.

Adrian Crum
Sandglass Software
www.sandglass-software.com


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [beanutils2] Assertions class vs. lang Validate

Simone Tripodi-2
In reply to this post by Matt Benson-2
Hi all,

between all options, Matt's one would be the one I'd support.

All the best,
-Simo

http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi


On Sat, Mar 1, 2014 at 8:45 PM, Matt Benson <[hidden email]> wrote:

> And just to add fuel to the fire and ensure every possible opinion is
> represented, I agree with Gary, but would support shading after the fact to
> reduce the dependency requirements.
>
> Matt
> On Mar 1, 2014 1:38 PM, "Paul Benedict" <[hidden email]> wrote:
>
> > I recommend copying the source of the Commons Lang classes you use and
> > maintain it privately. It is only two classes, right?
> > On Mar 1, 2014 12:51 PM, "André Diermann" <[hidden email]>
> > wrote:
> >
> > > But will upgrading to 1.7 will solve the core "issue", that some
> features
> > > (in detail: Assertions, MethodUitl and TypeUtil) are copied subsets of
> > > already implemented features in other Commons projects?
> > >
> > > From what I can see commons.lang3 is already referenced by BU2
> (although
> > > it's currently only used by TestBean).
> > >
> > >
> > >
> > >
> > > 2014-03-01 18:33 GMT+01:00 Benedikt Ritter <[hidden email]>:
> > >
> > > > I don't like the idea of creating some kind of component hierarchy,
> > where
> > > > components higher up may depend on lower levels libs. This should be
> > > > decided for every individual case.
> > > >
> > > > In the case of BU2 I'd say it's better to change the language level
> > > > requirement to 1.7. We could use Objects.notNull.
> > > > Other benefits include the new ReflectiveOperationException root
> > > exception
> > > > [1] which was introduced in Java 7 and the multi catch blocks. This
> > would
> > > > make the exception handling and wrapping code much more clearer.
> > > >
> > > > Benedikt
> > > >
> > > > [1]
> > > >
> > > >
> > >
> >
> http://docs.oracle.com/javase/7/docs/api/java/lang/ReflectiveOperationException.html
> > > >
> > > >
> > > > 2014-03-01 17:50 GMT+01:00 André Diermann <[hidden email]
> >:
> > > >
> > > > > Simon, that makes totally sense to me :) ..that's why I also often
> > > > struggle
> > > > > to use StringUtils for instance... but it starts with only one
> method
> > > and
> > > > > after some time I find myself in having copied a lot of methods.
> > > > >
> > > > > That's why I like Gary's idea too. Regarding BU2, MethodUtil and
> > > TypeUtil
> > > > > are also subsets from their lang pendants. So, when extending BU2
> > more
> > > > and
> > > > > more to BU's feature set, there might be even more copied
> methods...
> > > > >
> > > > > But I am not so deep in BU2's component architecture like you guys,
> > so
> > > to
> > > > > keep it lightweight is fine for more :) I was only wondering why it
> > was
> > > > not
> > > > > reused.
> > > > >
> > > > > Thank you.
> > > > >
> > > > >
> > > > > 2014-03-01 17:32 GMT+01:00 Gary Gregory <[hidden email]>:
> > > > >
> > > > > > My preference would be for components like [io] and [lang] to be
> > > reused
> > > > > > from other components as a dependency in order to avoid this kind
> > of
> > > > > > duplication.
> > > > > >
> > > > > > Gary
> > > > > >
> > > > > >
> > > > > > On Sat, Mar 1, 2014 at 11:27 AM, André Diermann <
> > > > > [hidden email]
> > > > > > >wrote:
> > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > I noticed that the majority (all?) functionality of the
> > Assertions
> > > > > class
> > > > > > is
> > > > > > > already covert by commons-lang Validate [1].
> > > > > > >
> > > > > > > For instance Assertions.checkNotNull() is an equivalent to
> > > > > > > Validate.notNull().
> > > > > > >
> > > > > > > Is there a reason for this?
> > > > > > >
> > > > > > > Regards,
> > > > > > > André
> > > > > > >
> > > > > > > [1]
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://commons.apache.org/proper/commons-lang/javadocs/api-release/index.html
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > E-Mail: [hidden email] | [hidden email]
> > > > > > Java Persistence with Hibernate, Second Edition<
> > > > > > http://www.manning.com/bauer3/>
> > > > > > JUnit in Action, Second Edition <
> http://www.manning.com/tahchiev/>
> > > > > > Spring Batch in Action <http://www.manning.com/templier/>
> > > > > > Blog: http://garygregory.wordpress.com
> > > > > > Home: http://garygregory.com/
> > > > > > Tweet! http://twitter.com/GaryGregory
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > http://people.apache.org/~britter/
> > > > http://www.systemoutprintln.de/
> > > > http://twitter.com/BenediktRitter
> > > > http://github.com/britter
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [beanutils2] Assertions class vs. lang Validate

Benedikt Ritter-4
In reply to this post by Adrian Crum-3
Hi Adrian


2014-03-02 8:03 GMT+01:00 Adrian Crum <[hidden email]>:

> On 3/1/2014 9:33 AM, Benedikt Ritter wrote:
>
>> I don't like the idea of creating some kind of component hierarchy, where
>> components higher up may depend on lower levels libs. This should be
>> decided for every individual case.
>>
>
> I agree. If I just want some basic low-level library, I don't want it to
> have a multitude of silly dependencies.
>
> One of the main problems with this community is the
> top-down-one-size-fits-all mentality. It just makes things a lot harder
> than they should be from a user's/developer's perspective.
>

I don't understand what you mean with this. Can you explain some more?


>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Reply | Threaded
Open this post in threaded view
|

Re: [beanutils2] Assertions class vs. lang Validate

Benedikt Ritter-4
In reply to this post by André Diermann
Hi André


2014-03-01 19:50 GMT+01:00 André Diermann <[hidden email]>:

> But will upgrading to 1.7 will solve the core "issue", that some features
> (in detail: Assertions, MethodUitl and TypeUtil) are copied subsets of
> already implemented features in other Commons projects?
>

The stuff that we have implemented in the Assertions class can be replaced
by the methods available in Objects from java 7. You're right about
MethodUtil and TypeUtil.


>
> From what I can see commons.lang3 is already referenced by BU2 (although
> it's currently only used by TestBean).
>

Yes, but a test dependency doesn't get pulled in a user declares a
dependency to BU2. It's just that we don't want that users have lang in
their class path just because we need two or three methods here and there.


>
>
>
>
> 2014-03-01 18:33 GMT+01:00 Benedikt Ritter <[hidden email]>:
>
> > I don't like the idea of creating some kind of component hierarchy, where
> > components higher up may depend on lower levels libs. This should be
> > decided for every individual case.
> >
> > In the case of BU2 I'd say it's better to change the language level
> > requirement to 1.7. We could use Objects.notNull.
> > Other benefits include the new ReflectiveOperationException root
> exception
> > [1] which was introduced in Java 7 and the multi catch blocks. This would
> > make the exception handling and wrapping code much more clearer.
> >
> > Benedikt
> >
> > [1]
> >
> >
> http://docs.oracle.com/javase/7/docs/api/java/lang/ReflectiveOperationException.html
> >
> >
> > 2014-03-01 17:50 GMT+01:00 André Diermann <[hidden email]>:
> >
> > > Simon, that makes totally sense to me :) ..that's why I also often
> > struggle
> > > to use StringUtils for instance... but it starts with only one method
> and
> > > after some time I find myself in having copied a lot of methods.
> > >
> > > That's why I like Gary's idea too. Regarding BU2, MethodUtil and
> TypeUtil
> > > are also subsets from their lang pendants. So, when extending BU2 more
> > and
> > > more to BU's feature set, there might be even more copied methods...
> > >
> > > But I am not so deep in BU2's component architecture like you guys, so
> to
> > > keep it lightweight is fine for more :) I was only wondering why it was
> > not
> > > reused.
> > >
> > > Thank you.
> > >
> > >
> > > 2014-03-01 17:32 GMT+01:00 Gary Gregory <[hidden email]>:
> > >
> > > > My preference would be for components like [io] and [lang] to be
> reused
> > > > from other components as a dependency in order to avoid this kind of
> > > > duplication.
> > > >
> > > > Gary
> > > >
> > > >
> > > > On Sat, Mar 1, 2014 at 11:27 AM, André Diermann <
> > > [hidden email]
> > > > >wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > I noticed that the majority (all?) functionality of the Assertions
> > > class
> > > > is
> > > > > already covert by commons-lang Validate [1].
> > > > >
> > > > > For instance Assertions.checkNotNull() is an equivalent to
> > > > > Validate.notNull().
> > > > >
> > > > > Is there a reason for this?
> > > > >
> > > > > Regards,
> > > > > André
> > > > >
> > > > > [1]
> > > > >
> > > > >
> > > >
> > >
> >
> http://commons.apache.org/proper/commons-lang/javadocs/api-release/index.html
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > E-Mail: [hidden email] | [hidden email]
> > > > Java Persistence with Hibernate, Second Edition<
> > > > http://www.manning.com/bauer3/>
> > > > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > > > Spring Batch in Action <http://www.manning.com/templier/>
> > > > Blog: http://garygregory.wordpress.com
> > > > Home: http://garygregory.com/
> > > > Tweet! http://twitter.com/GaryGregory
> > > >
> > >
> >
> >
> >
> > --
> > http://people.apache.org/~britter/
> > http://www.systemoutprintln.de/
> > http://twitter.com/BenediktRitter
> > http://github.com/britter
> >
>



--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Reply | Threaded
Open this post in threaded view
|

Re: [beanutils2] Assertions class vs. lang Validate

Benedikt Ritter-4
In reply to this post by Simone Tripodi-2
Hi,


2014-03-02 11:42 GMT+01:00 Simone Tripodi <[hidden email]>:

> Hi all,
>
> between all options, Matt's one would be the one I'd support.
>

Shading may be a solution. But tbh I don't see a problem here. We can
replace Assertions with Objects. That leaves us with MethodUtil (which
currently only provides detection of mapped setters and getters) and
TypeUtils (which does some Wrapper to Primitive type conversation).
Is it really worth the effort to do shading and stuff just to get rid of
this stuff?

Benedikt


>
> All the best,
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://twitter.com/simonetripodi
>
>
> On Sat, Mar 1, 2014 at 8:45 PM, Matt Benson <[hidden email]> wrote:
>
> > And just to add fuel to the fire and ensure every possible opinion is
> > represented, I agree with Gary, but would support shading after the fact
> to
> > reduce the dependency requirements.
> >
> > Matt
> > On Mar 1, 2014 1:38 PM, "Paul Benedict" <[hidden email]> wrote:
> >
> > > I recommend copying the source of the Commons Lang classes you use and
> > > maintain it privately. It is only two classes, right?
> > > On Mar 1, 2014 12:51 PM, "André Diermann" <[hidden email]>
> > > wrote:
> > >
> > > > But will upgrading to 1.7 will solve the core "issue", that some
> > features
> > > > (in detail: Assertions, MethodUitl and TypeUtil) are copied subsets
> of
> > > > already implemented features in other Commons projects?
> > > >
> > > > From what I can see commons.lang3 is already referenced by BU2
> > (although
> > > > it's currently only used by TestBean).
> > > >
> > > >
> > > >
> > > >
> > > > 2014-03-01 18:33 GMT+01:00 Benedikt Ritter <[hidden email]>:
> > > >
> > > > > I don't like the idea of creating some kind of component hierarchy,
> > > where
> > > > > components higher up may depend on lower levels libs. This should
> be
> > > > > decided for every individual case.
> > > > >
> > > > > In the case of BU2 I'd say it's better to change the language level
> > > > > requirement to 1.7. We could use Objects.notNull.
> > > > > Other benefits include the new ReflectiveOperationException root
> > > > exception
> > > > > [1] which was introduced in Java 7 and the multi catch blocks. This
> > > would
> > > > > make the exception handling and wrapping code much more clearer.
> > > > >
> > > > > Benedikt
> > > > >
> > > > > [1]
> > > > >
> > > > >
> > > >
> > >
> >
> http://docs.oracle.com/javase/7/docs/api/java/lang/ReflectiveOperationException.html
> > > > >
> > > > >
> > > > > 2014-03-01 17:50 GMT+01:00 André Diermann <
> [hidden email]
> > >:
> > > > >
> > > > > > Simon, that makes totally sense to me :) ..that's why I also
> often
> > > > > struggle
> > > > > > to use StringUtils for instance... but it starts with only one
> > method
> > > > and
> > > > > > after some time I find myself in having copied a lot of methods.
> > > > > >
> > > > > > That's why I like Gary's idea too. Regarding BU2, MethodUtil and
> > > > TypeUtil
> > > > > > are also subsets from their lang pendants. So, when extending BU2
> > > more
> > > > > and
> > > > > > more to BU's feature set, there might be even more copied
> > methods...
> > > > > >
> > > > > > But I am not so deep in BU2's component architecture like you
> guys,
> > > so
> > > > to
> > > > > > keep it lightweight is fine for more :) I was only wondering why
> it
> > > was
> > > > > not
> > > > > > reused.
> > > > > >
> > > > > > Thank you.
> > > > > >
> > > > > >
> > > > > > 2014-03-01 17:32 GMT+01:00 Gary Gregory <[hidden email]
> >:
> > > > > >
> > > > > > > My preference would be for components like [io] and [lang] to
> be
> > > > reused
> > > > > > > from other components as a dependency in order to avoid this
> kind
> > > of
> > > > > > > duplication.
> > > > > > >
> > > > > > > Gary
> > > > > > >
> > > > > > >
> > > > > > > On Sat, Mar 1, 2014 at 11:27 AM, André Diermann <
> > > > > > [hidden email]
> > > > > > > >wrote:
> > > > > > >
> > > > > > > > Hello,
> > > > > > > >
> > > > > > > > I noticed that the majority (all?) functionality of the
> > > Assertions
> > > > > > class
> > > > > > > is
> > > > > > > > already covert by commons-lang Validate [1].
> > > > > > > >
> > > > > > > > For instance Assertions.checkNotNull() is an equivalent to
> > > > > > > > Validate.notNull().
> > > > > > > >
> > > > > > > > Is there a reason for this?
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > André
> > > > > > > >
> > > > > > > > [1]
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://commons.apache.org/proper/commons-lang/javadocs/api-release/index.html
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > E-Mail: [hidden email] | [hidden email]
> > > > > > > Java Persistence with Hibernate, Second Edition<
> > > > > > > http://www.manning.com/bauer3/>
> > > > > > > JUnit in Action, Second Edition <
> > http://www.manning.com/tahchiev/>
> > > > > > > Spring Batch in Action <http://www.manning.com/templier/>
> > > > > > > Blog: http://garygregory.wordpress.com
> > > > > > > Home: http://garygregory.com/
> > > > > > > Tweet! http://twitter.com/GaryGregory
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > http://people.apache.org/~britter/
> > > > > http://www.systemoutprintln.de/
> > > > > http://twitter.com/BenediktRitter
> > > > > http://github.com/britter
> > > > >
> > > >
> > >
> >
>



--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Reply | Threaded
Open this post in threaded view
|

Re: [beanutils2] Assertions class vs. lang Validate

André Diermann
In reply to this post by Benedikt Ritter-4
2014-03-03 9:10 GMT+01:00 Benedikt Ritter <[hidden email]>:
>
>
> The stuff that we have implemented in the Assertions class can be replaced
> by the methods available in Objects from java 7. You're right about
> MethodUtil and TypeUtil.
>
>
Just to be clear what you mean by replace:
- wrapping the methods from Objects in the Assertions class to keep the API
or
- get rid of the Assertions class completly and directly use the methods
from Objects class.

If okay, I would like to create a ticket and to provide a patch for this
tonight :)


>
> Yes, but a test dependency doesn't get pulled in a user declares a
> dependency to BU2. It's just that we don't want that users have lang in
> their class path just because we need two or three methods here and there.
>

Ok, that makes sense. :)
Reply | Threaded
Open this post in threaded view
|

Re: [beanutils2] Assertions class vs. lang Validate

Benedikt Ritter-4
Hello André

2014-03-03 9:57 GMT+01:00 André Diermann <[hidden email]>:

> 2014-03-03 9:10 GMT+01:00 Benedikt Ritter <[hidden email]>:
> >
> >
> > The stuff that we have implemented in the Assertions class can be
> replaced
> > by the methods available in Objects from java 7. You're right about
> > MethodUtil and TypeUtil.
> >
> >
> Just to be clear what you mean by replace:
> - wrapping the methods from Objects in the Assertions class to keep the API
> or
> - get rid of the Assertions class completly and directly use the methods
> from Objects class.
>
> If okay, I would like to create a ticket and to provide a patch for this
> tonight :)
>

I'd say let's go for the latter. Assertions is an internal class (package
private) so there is no need to keep it.

Benedikt


>
>
> >
> > Yes, but a test dependency doesn't get pulled in a user declares a
> > dependency to BU2. It's just that we don't want that users have lang in
> > their class path just because we need two or three methods here and
> there.
> >
>
> Ok, that makes sense. :)
>



--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Reply | Threaded
Open this post in threaded view
|

Re: [beanutils2] Assertions class vs. lang Validate

Simone Tripodi-2
In reply to this post by Benedikt Ritter-4
On Mon, Mar 3, 2014 at 9:13 AM, Benedikt Ritter <[hidden email]> wrote:

> Hi,
>
>
> 2014-03-02 11:42 GMT+01:00 Simone Tripodi <[hidden email]>:
>
> > Hi all,
> >
> > between all options, Matt's one would be the one I'd support.
> >
>
> Shading may be a solution. But tbh I don't see a problem here. We can
> replace Assertions with Objects. That leaves us with MethodUtil (which
> currently only provides detection of mapped setters and getters) and
> TypeUtils (which does some Wrapper to Primitive type conversation).
> Is it really worth the effort to do shading and stuff just to get rid of
> this stuff?
>
>
I haven't seen any final decision to upgrade or not to jdk7 nor any action
taken
I personally don't have any preference since it is a hobby project for me

http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi


> Benedikt
>
>
> >
> > All the best,
> > -Simo
> >
> > http://people.apache.org/~simonetripodi/
> > http://twitter.com/simonetripodi
> >
> >
> > On Sat, Mar 1, 2014 at 8:45 PM, Matt Benson <[hidden email]>
> wrote:
> >
> > > And just to add fuel to the fire and ensure every possible opinion is
> > > represented, I agree with Gary, but would support shading after the
> fact
> > to
> > > reduce the dependency requirements.
> > >
> > > Matt
> > > On Mar 1, 2014 1:38 PM, "Paul Benedict" <[hidden email]> wrote:
> > >
> > > > I recommend copying the source of the Commons Lang classes you use
> and
> > > > maintain it privately. It is only two classes, right?
> > > > On Mar 1, 2014 12:51 PM, "André Diermann" <[hidden email]>
> > > > wrote:
> > > >
> > > > > But will upgrading to 1.7 will solve the core "issue", that some
> > > features
> > > > > (in detail: Assertions, MethodUitl and TypeUtil) are copied subsets
> > of
> > > > > already implemented features in other Commons projects?
> > > > >
> > > > > From what I can see commons.lang3 is already referenced by BU2
> > > (although
> > > > > it's currently only used by TestBean).
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > 2014-03-01 18:33 GMT+01:00 Benedikt Ritter <[hidden email]>:
> > > > >
> > > > > > I don't like the idea of creating some kind of component
> hierarchy,
> > > > where
> > > > > > components higher up may depend on lower levels libs. This should
> > be
> > > > > > decided for every individual case.
> > > > > >
> > > > > > In the case of BU2 I'd say it's better to change the language
> level
> > > > > > requirement to 1.7. We could use Objects.notNull.
> > > > > > Other benefits include the new ReflectiveOperationException root
> > > > > exception
> > > > > > [1] which was introduced in Java 7 and the multi catch blocks.
> This
> > > > would
> > > > > > make the exception handling and wrapping code much more clearer.
> > > > > >
> > > > > > Benedikt
> > > > > >
> > > > > > [1]
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://docs.oracle.com/javase/7/docs/api/java/lang/ReflectiveOperationException.html
> > > > > >
> > > > > >
> > > > > > 2014-03-01 17:50 GMT+01:00 André Diermann <
> > [hidden email]
> > > >:
> > > > > >
> > > > > > > Simon, that makes totally sense to me :) ..that's why I also
> > often
> > > > > > struggle
> > > > > > > to use StringUtils for instance... but it starts with only one
> > > method
> > > > > and
> > > > > > > after some time I find myself in having copied a lot of
> methods.
> > > > > > >
> > > > > > > That's why I like Gary's idea too. Regarding BU2, MethodUtil
> and
> > > > > TypeUtil
> > > > > > > are also subsets from their lang pendants. So, when extending
> BU2
> > > > more
> > > > > > and
> > > > > > > more to BU's feature set, there might be even more copied
> > > methods...
> > > > > > >
> > > > > > > But I am not so deep in BU2's component architecture like you
> > guys,
> > > > so
> > > > > to
> > > > > > > keep it lightweight is fine for more :) I was only wondering
> why
> > it
> > > > was
> > > > > > not
> > > > > > > reused.
> > > > > > >
> > > > > > > Thank you.
> > > > > > >
> > > > > > >
> > > > > > > 2014-03-01 17:32 GMT+01:00 Gary Gregory <
> [hidden email]
> > >:
> > > > > > >
> > > > > > > > My preference would be for components like [io] and [lang] to
> > be
> > > > > reused
> > > > > > > > from other components as a dependency in order to avoid this
> > kind
> > > > of
> > > > > > > > duplication.
> > > > > > > >
> > > > > > > > Gary
> > > > > > > >
> > > > > > > >
> > > > > > > > On Sat, Mar 1, 2014 at 11:27 AM, André Diermann <
> > > > > > > [hidden email]
> > > > > > > > >wrote:
> > > > > > > >
> > > > > > > > > Hello,
> > > > > > > > >
> > > > > > > > > I noticed that the majority (all?) functionality of the
> > > > Assertions
> > > > > > > class
> > > > > > > > is
> > > > > > > > > already covert by commons-lang Validate [1].
> > > > > > > > >
> > > > > > > > > For instance Assertions.checkNotNull() is an equivalent to
> > > > > > > > > Validate.notNull().
> > > > > > > > >
> > > > > > > > > Is there a reason for this?
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > > André
> > > > > > > > >
> > > > > > > > > [1]
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://commons.apache.org/proper/commons-lang/javadocs/api-release/index.html
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > E-Mail: [hidden email] | [hidden email]
> > > > > > > > Java Persistence with Hibernate, Second Edition<
> > > > > > > > http://www.manning.com/bauer3/>
> > > > > > > > JUnit in Action, Second Edition <
> > > http://www.manning.com/tahchiev/>
> > > > > > > > Spring Batch in Action <http://www.manning.com/templier/>
> > > > > > > > Blog: http://garygregory.wordpress.com
> > > > > > > > Home: http://garygregory.com/
> > > > > > > > Tweet! http://twitter.com/GaryGregory
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > http://people.apache.org/~britter/
> > > > > > http://www.systemoutprintln.de/
> > > > > > http://twitter.com/BenediktRitter
> > > > > > http://github.com/britter
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>
Reply | Threaded
Open this post in threaded view
|

Re: [beanutils2] Assertions class vs. lang Validate

Simone Tripodi-2
In reply to this post by Benedikt Ritter-4
go for it! :)

http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi


On Mon, Mar 3, 2014 at 10:53 AM, Benedikt Ritter <[hidden email]> wrote:

> Hello André
>
> 2014-03-03 9:57 GMT+01:00 André Diermann <[hidden email]>:
>
> > 2014-03-03 9:10 GMT+01:00 Benedikt Ritter <[hidden email]>:
> > >
> > >
> > > The stuff that we have implemented in the Assertions class can be
> > replaced
> > > by the methods available in Objects from java 7. You're right about
> > > MethodUtil and TypeUtil.
> > >
> > >
> > Just to be clear what you mean by replace:
> > - wrapping the methods from Objects in the Assertions class to keep the
> API
> > or
> > - get rid of the Assertions class completly and directly use the methods
> > from Objects class.
> >
> > If okay, I would like to create a ticket and to provide a patch for this
> > tonight :)
> >
>
> I'd say let's go for the latter. Assertions is an internal class (package
> private) so there is no need to keep it.
>
> Benedikt
>
>
> >
> >
> > >
> > > Yes, but a test dependency doesn't get pulled in a user declares a
> > > dependency to BU2. It's just that we don't want that users have lang in
> > > their class path just because we need two or three methods here and
> > there.
> > >
> >
> > Ok, that makes sense. :)
> >
>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>
Reply | Threaded
Open this post in threaded view
|

Re: [beanutils2] Assertions class vs. lang Validate

Adrian Crum-3
In reply to this post by Benedikt Ritter-4
The Assertions class works fine and it serves its purpose. There is no
need to make the library dependent on another library.

Going that route, as a developer/user of the library, I would be forced
to download and install two libraries instead of one. So it is more
complication and work for me.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 3/3/2014 12:07 AM, Benedikt Ritter wrote:

> Hi Adrian
>
>
> 2014-03-02 8:03 GMT+01:00 Adrian Crum <[hidden email]>:
>
>> On 3/1/2014 9:33 AM, Benedikt Ritter wrote:
>>
>>> I don't like the idea of creating some kind of component hierarchy, where
>>> components higher up may depend on lower levels libs. This should be
>>> decided for every individual case.
>>>
>>
>> I agree. If I just want some basic low-level library, I don't want it to
>> have a multitude of silly dependencies.
>>
>> One of the main problems with this community is the
>> top-down-one-size-fits-all mentality. It just makes things a lot harder
>> than they should be from a user's/developer's perspective.
>>
>
> I don't understand what you mean with this. Can you explain some more?
>
>
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12