[beanutils] Toward 2.0.0

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

[beanutils] Toward 2.0.0

garydgregory
Hi All,

- BeanUtils now has a new package o.a.c.beanutils2.
- BeanUtils now depends on Apache Commons Collection 4 (instead of 3),
which caused the above.

What more do we want before releasing 2.0.0?

Updating from BU 1.x to 2.x should be "simple" for now: Just update your
imports.

Thoughts?

Gary
Reply | Threaded
Open this post in threaded view
|

Re: [beanutils] Toward 2.0.0

sebb-2-2
On 28 December 2017 at 19:49, Gary Gregory <[hidden email]> wrote:

> Hi All,
>
> - BeanUtils now has a new package o.a.c.beanutils2.
> - BeanUtils now depends on Apache Commons Collection 4 (instead of 3),
> which caused the above.
>
> What more do we want before releasing 2.0.0?
>
> Updating from BU 1.x to 2.x should be "simple" for now: Just update your
> imports.

Surely there must be some other breaking changes otherwise there would
be no need to change the package name?

> 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] Toward 2.0.0

dbrosIus
beanutils 3 exposed 'FastHashMap' which was a commons collections 3 data
structure in it's own interface. That went away in commons collections
4, and so i modified the beanutils 4 interface to use
ConcurrentHashMaps. Thus the need for a package rename.


On 12/28/2017 04:56 PM, sebb wrote:

> On 28 December 2017 at 19:49, Gary Gregory <[hidden email]> wrote:
>> Hi All,
>>
>> - BeanUtils now has a new package o.a.c.beanutils2.
>> - BeanUtils now depends on Apache Commons Collection 4 (instead of 3),
>> which caused the above.
>>
>> What more do we want before releasing 2.0.0?
>>
>> Updating from BU 1.x to 2.x should be "simple" for now: Just update your
>> imports.
> Surely there must be some other breaking changes otherwise there would
> be no need to change the package name?
>
>> Thoughts?
>>
>> Gary
> ---------------------------------------------------------------------
> 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] Toward 2.0.0

sebb-2-2
On 28 December 2017 at 22:02, Dave Brosius <[hidden email]> wrote:
> beanutils 3 exposed 'FastHashMap' which was a commons collections 3 data
> structure in it's own interface. That went away in commons collections 4,
> and so i modified the beanutils 4 interface to use ConcurrentHashMaps. Thus
> the need for a package rename.

I see. So it's not just a case of changing imports.

If any user code has used that part of the interface, it will have to
be changed.

>
>
> On 12/28/2017 04:56 PM, sebb wrote:
>>
>> On 28 December 2017 at 19:49, Gary Gregory <[hidden email]> wrote:
>>>
>>> Hi All,
>>>
>>> - BeanUtils now has a new package o.a.c.beanutils2.
>>> - BeanUtils now depends on Apache Commons Collection 4 (instead of 3),
>>> which caused the above.
>>>
>>> What more do we want before releasing 2.0.0?
>>>
>>> Updating from BU 1.x to 2.x should be "simple" for now: Just update your
>>> imports.
>>
>> Surely there must be some other breaking changes otherwise there would
>> be no need to change the package name?
>>
>>> Thoughts?
>>>
>>> Gary
>>
>> ---------------------------------------------------------------------
>> 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]
>

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

Reply | Threaded
Open this post in threaded view
|

Re: [beanutils] Toward 2.0.0

jodastephen
In reply to this post by garydgregory
On 28 December 2017 at 19:49, Gary Gregory <[hidden email]> wrote:

> Hi All,
>
> - BeanUtils now has a new package o.a.c.beanutils2.
> - BeanUtils now depends on Apache Commons Collection 4 (instead of 3),
> which caused the above.
>
> What more do we want before releasing 2.0.0?
>
> Updating from BU 1.x to 2.x should be "simple" for now: Just update your
> imports.

This can make things far worse for end users. If jar file A updates to
v2.0 but jar file B does not, an application C that depends on A and B
cannot pass the output of [beanutils] around. Instead, it gets the
same class names repeated twice, and horrid conversion code. While I
understand the jar hell problem fully, I'm not sure that package
renaming the whole jar is really any better - its just a different
kind of hell.

If only one class exposes one problem return type in a method that not
everyone uses, it seems _on balance_ better to change the method
without changing the package names. The bump to v2.0 would still be a
sufficient indication of the potential compatibility issue (rarely hit
in reality). However, if the method in question is a vital part of the
main API, it might be worth changing the package name.

In other words, I think the presumption that all breaking changes
require a package name change is damaging - the package name change
should be an action of last resort.

Stephen

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

Reply | Threaded
Open this post in threaded view
|

Re: [beanutils] Toward 2.0.0

sebb-2-2
On 28 December 2017 at 22:50, Stephen Colebourne <[hidden email]> wrote:

> On 28 December 2017 at 19:49, Gary Gregory <[hidden email]> wrote:
>> Hi All,
>>
>> - BeanUtils now has a new package o.a.c.beanutils2.
>> - BeanUtils now depends on Apache Commons Collection 4 (instead of 3),
>> which caused the above.
>>
>> What more do we want before releasing 2.0.0?
>>
>> Updating from BU 1.x to 2.x should be "simple" for now: Just update your
>> imports.
>
> This can make things far worse for end users. If jar file A updates to
> v2.0 but jar file B does not, an application C that depends on A and B
> cannot pass the output of [beanutils] around. Instead, it gets the
> same class names repeated twice, and horrid conversion code. While I
> understand the jar hell problem fully, I'm not sure that package
> renaming the whole jar is really any better - its just a different
> kind of hell.

At least it's possible to write bridging code should it be necessary.
And any problems are immediately obvious.

Whereas if two incompatible jars are on the classpath, there's no way
to ensure which version of a class will be loaded.
And problems may not always appear until the worst possible moment.

Other things being equal (see below), I would rather have a situation
with a messy solution than a situation with none.

> If only one class exposes one problem return type in a method that not
> everyone uses, it seems _on balance_ better to change the method
> without changing the package names. The bump to v2.0 would still be a
> sufficient indication of the potential compatibility issue (rarely hit
> in reality). However, if the method in question is a vital part of the
> main API, it might be worth changing the package name.
>
> In other words, I think the presumption that all breaking changes
> require a package name change is damaging - the package name change
> should be an action of last resort.

I agree that some changes that break strict compatibility may
sometimes be permissible.
If the change only affects an esoteric or non-recommended use of the
API then it's probably better to keep the existing package.
However that assumes there is a work-round for any users who are affected.

> Stephen
>
> ---------------------------------------------------------------------
> 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] Toward 2.0.0

Benedikt Ritter-4
In reply to this post by garydgregory
Hi,

> Am 28.12.2017 um 20:49 schrieb Gary Gregory <[hidden email]>:
>
> Hi All,
>
> - BeanUtils now has a new package o.a.c.beanutils2.
> - BeanUtils now depends on Apache Commons Collection 4 (instead of 3),
> which caused the above.
>
> What more do we want before releasing 2.0.0?
>
> Updating from BU 1.x to 2.x should be "simple" for now: Just update your
> imports.
>
> Thoughts?

See my comment on the other thread. What about the BeanUtils rewrite we have in the Sandbox?

>
> Gary


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