[beanutils] Towards 2.0?

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

[beanutils] Towards 2.0?

Rob Tompkins
Curious if anyone has any thoughts here on what needs to be done as we work towards a 2.0 for beanutils…..does anyone else want to get anything in. I know that there’s considerable demand for it out there.

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

Reply | Threaded
Open this post in threaded view
|

Re: [beanutils] Towards 2.0?

garydgregory
I think we had talked in the past about not letting Commons Collections
APIs "leak" out of the BeanUtils API.

Gary

On Sun, Oct 13, 2019, 20:16 Rob Tompkins <[hidden email]> wrote:

> Curious if anyone has any thoughts here on what needs to be done as we
> work towards a 2.0 for beanutils…..does anyone else want to get anything
> in. I know that there’s considerable demand for it out there.
>
> Cheers,
> -Rob
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [beanutils] Towards 2.0?

Rob Tompkins
Ah…good point….just saw that bit from BEANUTILS-520 -Rob

> On Oct 13, 2019, at 11:42 PM, Gary Gregory <[hidden email]> wrote:
>
> I think we had talked in the past about not letting Commons Collections
> APIs "leak" out of the BeanUtils API.
>
> Gary
>
> On Sun, Oct 13, 2019, 20:16 Rob Tompkins <[hidden email]> wrote:
>
>> Curious if anyone has any thoughts here on what needs to be done as we
>> work towards a 2.0 for beanutils…..does anyone else want to get anything
>> in. I know that there’s considerable demand for it out there.
>>
>> Cheers,
>> -Rob
>> ---------------------------------------------------------------------
>> 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]

Reply | Threaded
Open this post in threaded view
|

Re: [beanutils] Towards 2.0?

Melloware Inc
In reply to this post by Rob Tompkins
+1 from me


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

Reply | Threaded
Open this post in threaded view
|

Re: [beanutils] Towards 2.0?

garydgregory
On Mon, Oct 14, 2019 at 4:11 PM Melloware <[hidden email]> wrote:

> +1 from me
>

What is your +1 about?

Gary


>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [beanutils] Towards 2.0?

Melloware Inc
In reply to this post by Rob Tompkins
+1 as in I think the library is ready to go "as is" for 2.0 release. 
It's a feature rich stable library.

It has always had the Commons Collections stuff in there but if you feel
the need to rip it out then rip it out.  If not then I would just
release the 2.0 version of the library.


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

Reply | Threaded
Open this post in threaded view
|

Re: [beanutils] Towards 2.0?

garydgregory
On Thu, Oct 17, 2019 at 11:33 AM Melloware <[hidden email]> wrote:

> +1 as in I think the library is ready to go "as is" for 2.0 release.
> It's a feature rich stable library.
>
> It has always had the Commons Collections stuff in there but if you feel
> the need to rip it out then rip it out.  If not then I would just
> release the 2.0 version of the library.
>

This is not about ripping out anything. The only reason we are going with a
major release change is because we updated from Commons Collection from 3
to 4, and since some BU APIs "leak" Commons Collections types, it breaks
compatibility.

The question is: Do we really want Commons Collection types to be in BU
signatures, or would Java Collections be sufficient?

For example:

org.apache.commons.beanutils2.BeanPredicate
implements org.apache.commons.collections4.Predicate<T>.

It seems like org.apache.commons.collections4.Predicate<T> can/should be
replaced by java.util.function.Function<T, R>

The internals of BU can still use Commons Collections.

Thoughts?

Gary


>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [beanutils] Towards 2.0?

Melloware Inc
In reply to this post by Rob Tompkins
Gary,

I misunderstood I apologize.

I see you are saying convert anywhere we are using Commons Collections
with JDK8 native calls then yes I would definitely support that.

Let me see if I can take a crack at it and submit a PR.

Melloware



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

Reply | Threaded
Open this post in threaded view
|

Re: [beanutils] Towards 2.0?

Emmanuel Bourg-3
In reply to this post by garydgregory
Le 17/10/2019 à 19:45, Gary Gregory a écrit :

> It seems like org.apache.commons.collections4.Predicate<T> can/should be
> replaced by java.util.function.Function<T, R>

Did we consider modifying collections4 such that Predicate extends
Function? That would ease the transition to the Java 8 types.

Emmanuel Bourg

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

Reply | Threaded
Open this post in threaded view
|

Re: [beanutils] Towards 2.0?

garydgregory
On Mon, Oct 21, 2019 at 2:53 AM Emmanuel Bourg <[hidden email]> wrote:

> Le 17/10/2019 à 19:45, Gary Gregory a écrit :
>
> > It seems like org.apache.commons.collections4.Predicate<T> can/should be
> > replaced by java.util.function.Function<T, R>
>
> Did we consider modifying collections4 such that Predicate extends
> Function? That would ease the transition to the Java 8 types.
>

Happy Monday to all,

Since the next version is 2.0, we can break backward compatibility and use
java.util.function directly. See git master where there is only one
remaining dependency on Commons Collections.

See also https://issues.apache.org/jira/browse/BEANUTILS-527 for a few more
migratory details.

I am thinking we can consider making the remaining dependency a private
static class or, implement the feature differently. I am looking for
opinions here...

The other question is what to do with Collection's Transformer class. There
at the very least we can make it a subtype of Java's own Function. We can
also just deprecate Transformer in favor of Function. It depends on how
much value there is in a functional interface called "Transformer" vs the
more general "Function". I think in the end, Transformer should be
deprecated in favor of Function.

Thoughts?

Thank you!
Gary


>
> Emmanuel Bourg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [beanutils] Towards 2.0?

garydgregory
Also toward 2.0, we need to collapse:

org.apache.commons.beanutils2.BeanUtilsBean
org.apache.commons.beanutils2.BeanUtilsBean2

and

org.apache.commons.beanutils2.ConvertUtilsBean
org.apache.commons.beanutils2.ConvertUtilsBean2

and probably add classes in org.apache.commons.beanutils2.converters for
URI, Path and UUID perhaps.

PRs welcome.

Gary

On Mon, Oct 21, 2019 at 8:55 AM Gary Gregory <[hidden email]> wrote:

> On Mon, Oct 21, 2019 at 2:53 AM Emmanuel Bourg <[hidden email]> wrote:
>
>> Le 17/10/2019 à 19:45, Gary Gregory a écrit :
>>
>> > It seems like org.apache.commons.collections4.Predicate<T> can/should be
>> > replaced by java.util.function.Function<T, R>
>>
>> Did we consider modifying collections4 such that Predicate extends
>> Function? That would ease the transition to the Java 8 types.
>>
>
> Happy Monday to all,
>
> Since the next version is 2.0, we can break backward compatibility and use
> java.util.function directly. See git master where there is only one
> remaining dependency on Commons Collections.
>
> See also https://issues.apache.org/jira/browse/BEANUTILS-527 for a few
> more migratory details.
>
> I am thinking we can consider making the remaining dependency a private
> static class or, implement the feature differently. I am looking for
> opinions here...
>
> The other question is what to do with Collection's Transformer class.
> There at the very least we can make it a subtype of Java's own Function. We
> can also just deprecate Transformer in favor of Function. It depends on how
> much value there is in a functional interface called "Transformer" vs the
> more general "Function". I think in the end, Transformer should be
> deprecated in favor of Function.
>
> Thoughts?
>
> Thank you!
> Gary
>
>
>>
>> Emmanuel Bourg
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>