Re: [beanutils] Toward 2.0.0

[Benedikt Ritter]

Hi,

> Am 28.12.2017 um 20:49 schrieb Gary Gregory :
> 
> 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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [beanutils] Toward 2.0.0

[sebb]

On 28 December 2017 at 22:50, Stephen Colebourne  wrote:
> On 28 December 2017 at 19:49, Gary Gregory  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: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [beanutils] Toward 2.0.0

[Stephen Colebourne]

On 28 December 2017 at 19:49, Gary Gregory  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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [beanutils] Toward 2.0.0

[sebb]

On 28 December 2017 at 22:02, Dave Brosius  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  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: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [beanutils] Toward 2.0.0

[Dave Brosius]

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  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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [beanutils] Toward 2.0.0

[sebb]

On 28 December 2017 at 19:49, Gary Gregory  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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[beanutils] Toward 2.0.0

[Gary Gregory]

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