You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Torsten Curdt <tc...@apache.org> on 2007/05/18 12:42:07 UTC
[beanutils] commons collection classes
Grrrr... why oh why are commmons collection classes inside beanutils?!
@!@#$@
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [beanutils] commons collection classes
Posted by Torsten Curdt <tc...@apache.org>.
>> Now this is the part that I don't understand. Why would that have
>> been an incompatible change? The changes should have been internal to
>> beanutils.
>
> Because BeanUtils exposes FastHashMap in its public API (and Digester
> does the same with ArrayStack) - its the return type from four
> methods.
Ahhh ...bugger!
> The bad news was that an implementation (rather than Map) was exposed
> in the API in the first place. It does seem pretty minor to me
> changing that API from FastHashMap --> Map in only 4 places that
> probably aren't used outside BeanUtils.
>
> Having said that - the current situation has been in place for over 2
> years and there haven't been complaints until now. Just out of
> interest which of the 4 classes caused you a problem?
I was tracking down classpath clashes in other areas and basically
just did a full check ...and just came across this. I think people
are just no aware they are using the old version provided by beanutils.
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [beanutils] commons collection classes
Posted by Rahul Akolkar <ra...@gmail.com>.
On 5/18/07, Niall Pemberton <ni...@gmail.com> wrote:
<snip/>
>
> Having said that - the current situation has been in place for over 2
> years and there haven't been complaints until now.
<snap/>
Yup, and I don't perceive any urgency here (not that I'd want us to
recommend this again).
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [beanutils] commons collection classes
Posted by Niall Pemberton <ni...@gmail.com>.
On 5/18/07, Torsten Curdt <tc...@apache.org> wrote:
>
> On 18.05.2007, at 18:37, Stephen Colebourne wrote:
>
> > Torsten Curdt wrote:
> >> On 18.05.2007, at 13:57, Niall Pemberton wrote:
> >>> I wasn't part of the decision at the time, but (at least some if not
> >>> all) these classes are in the BeanUtils public API so changing the
> >>> package would have (and still will) broken binary compatibility (to
> >>> remove the dependency on Collections 'coz of its incompatibility
> >>> between versions!) - they were copied and (AFAIK) the parts of the
> >>> public API deprecated with the intention of removing them in the
> >>> next
> >>> release - but there hasn't been one since that was done and 1.7.0
> >>> released.
> >> I am not pointing fingers. But whatever it takes - having those
> >> classes in there like this is not acceptable and needs to be fixed
> >> ASAP.
> >
> > Whilst it may have frustrated you recently, the current situation
> > really isn't that bad. It allowed [beanutils] to drop a 500Kb
> > dependency on [collections] in a simple manner.
>
> Basically promoting class path clashes is "not that bad"????
>
> I personally think that dropping a dependency because of size does
> not really make too much sense these days. If someone is concerned
> there are tools to solve these needs
>
> http://mojo.codehaus.org/minijar-maven-plugin/usage.html
> http://proguard.sourceforge.net/
>
> > The copy was permitted as there were few classes involved, and they
> > were very stable.
> >
> > Changing the package name would have been, and still is, backwards
> > incompatible. As such it is unacceptable for such a widely used
> > package as [beanutils]. I am -1 to arbitrarily changing the package
> > name.
>
> Now this is the part that I don't understand. Why would that have
> been an incompatible change? The changes should have been internal to
> beanutils.
Because BeanUtils exposes FastHashMap in its public API (and Digester
does the same with ArrayStack) - its the return type from four
methods.
The bad news was that an implementation (rather than Map) was exposed
in the API in the first place. It does seem pretty minor to me
changing that API from FastHashMap --> Map in only 4 places that
probably aren't used outside BeanUtils.
Having said that - the current situation has been in place for over 2
years and there haven't been complaints until now. Just out of
interest which of the 4 classes caused you a problem?
Niall
> > We really need a prime directive in commons. Don't break backwards
> > compatibility. Every time we do we cause problems down the line -
> > its simple due to our status as the lowest of low libraries. And
> > again, this also emphasises that each commons library works much
> > better when it stands alone - no dependencies.
>
> We could release ueberjars with unused classes removed and just would
> no longer have to care.
>
> cheers
> --
> Torsten
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [beanutils] commons collection classes
Posted by Torsten Curdt <tc...@apache.org>.
On 18.05.2007, at 18:37, Stephen Colebourne wrote:
> Torsten Curdt wrote:
>> On 18.05.2007, at 13:57, Niall Pemberton wrote:
>>> I wasn't part of the decision at the time, but (at least some if not
>>> all) these classes are in the BeanUtils public API so changing the
>>> package would have (and still will) broken binary compatibility (to
>>> remove the dependency on Collections 'coz of its incompatibility
>>> between versions!) - they were copied and (AFAIK) the parts of the
>>> public API deprecated with the intention of removing them in the
>>> next
>>> release - but there hasn't been one since that was done and 1.7.0
>>> released.
>> I am not pointing fingers. But whatever it takes - having those
>> classes in there like this is not acceptable and needs to be fixed
>> ASAP.
>
> Whilst it may have frustrated you recently, the current situation
> really isn't that bad. It allowed [beanutils] to drop a 500Kb
> dependency on [collections] in a simple manner.
Basically promoting class path clashes is "not that bad"????
I personally think that dropping a dependency because of size does
not really make too much sense these days. If someone is concerned
there are tools to solve these needs
http://mojo.codehaus.org/minijar-maven-plugin/usage.html
http://proguard.sourceforge.net/
> The copy was permitted as there were few classes involved, and they
> were very stable.
>
> Changing the package name would have been, and still is, backwards
> incompatible. As such it is unacceptable for such a widely used
> package as [beanutils]. I am -1 to arbitrarily changing the package
> name.
Now this is the part that I don't understand. Why would that have
been an incompatible change? The changes should have been internal to
beanutils.
> We really need a prime directive in commons. Don't break backwards
> compatibility. Every time we do we cause problems down the line -
> its simple due to our status as the lowest of low libraries. And
> again, this also emphasises that each commons library works much
> better when it stands alone - no dependencies.
We could release ueberjars with unused classes removed and just would
no longer have to care.
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [beanutils] commons collection classes
Posted by James Carman <ja...@carmanconsulting.com>.
This is a major "broken window", IMHO, and it should be fixed. Why not
leave the API the way it is and just take out the classes that are
duplicated? They are in the same packages as are in the commons-collections
jar file. I understand that it causes a dependency on commons collections
(which is big), but at least the user knows what exactly they're getting
rather than playing classloader bingo. Also, the dependency is a
conditional one. You only need collections if you're using these specific
classes. There are probably not too many users of these classes anyway. I
would venture to say that there are probably not too many projects using
beanutils that aren't using collections anyway (once you start playing with
commons libraries, you can't stop; they're addictive).
On 5/19/07, Stephen Colebourne <sc...@btopenworld.com> wrote:
>
> Torsten Curdt wrote:
> > On 18.05.2007, at 21:56, Thorbjørn Ravn Andersen wrote:
> >> I suggest marking the offending methods as deprecated for the 1.x
> >> series, and schedule them for removal in the 2.x series.
> >
> > Well, then let's create a 2.x branch and do a release without the
> > classes *now*. No problem with that. Then it is communicated and people
> > can choose. But doing *nothing* just because of binary compatibility is
> > silly.
>
> Doing nothing because of binary incompatibility is not silly, its
> essential. Commons has to be far more extreme than almost any other OSS
> project on this point.
>
> In fact, I contend that commons is now in such a position that we can't
> make incompatible changes even in major version number releases.
>
> > Especially as no one *has* to upgrade libraries. And checking
> > release notes if you do can't hurt if you upgrade.
>
> Users are forced to upgrade all the time, and thats why they require
> backwards compatibility.
>
> For example, if project A is complied against the old [beanutils] jar,
> while project B is compiled against the new [beanutils] jar, then it is
> impossible to use both project A and project B together. You cannot
> physically upgrade the jar file to the one B needs, because A needs the
> old one.
>
> The only solutions to this at present are
> - for the 2.x series to have a different package name, including 'v2'
> - to force the user to play with class loaders, so they can load two
> different versions of the same class
>
>
> In summary, I suggest we all just let this one be. This isn't causing
> major pain IMO. The lesson should be to not have dependencies between
> commons projects wherever possible.
>
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [beanutils] commons collection classes
Posted by Torsten Curdt <tc...@apache.org>.
On 19.05.2007, at 21:37, Stephen Colebourne wrote:
> Torsten Curdt wrote:
>> On 18.05.2007, at 21:56, Thorbjørn Ravn Andersen wrote:
>>> I suggest marking the offending methods as deprecated for the 1.x
>>> series, and schedule them for removal in the 2.x series.
>> Well, then let's create a 2.x branch and do a release without the
>> classes *now*. No problem with that. Then it is communicated and
>> people can choose. But doing *nothing* just because of binary
>> compatibility is silly.
>
> Doing nothing because of binary incompatibility is not silly, its
> essential. Commons has to be far more extreme than almost any other
> OSS project on this point.
Sticking to the broken takes compatibility to another level. Whether
that is what the users demand - I doubt it.
> In fact, I contend that commons is now in such a position that we
> can't make incompatible changes even in major version number releases.
What are major version number releases for then in your opinion?
>> Especially as no one *has* to upgrade libraries. And checking
>> release notes if you do can't hurt if you upgrade.
>
> Users are forced to upgrade all the time, and thats why they
> require backwards compatibility.
> For example, if project A is complied against the old [beanutils]
> jar, while project B is compiled against the new [beanutils] jar,
> then it is impossible to use both project A and project B together.
> You cannot physically upgrade the jar file to the one B needs,
> because A needs the old one.
> The only solutions to this at present are
> - for the 2.x series to have a different package name, including 'v2'
> - to force the user to play with class loaders, so they can load
> two different versions of the same class
Have self contained jars and the problem (more or less) vanishes
because A comes with just the code it needs from the old beanutils
jar and B comes the new beanutils code. Unfortunately this will only
work if the underlying dependency does not get exposed - like we have
in this case. So we still have to be careful. But it would give a
whole lot more freedom for changes and re-use IMO.
> In summary, I suggest we all just let this one be. This isn't
> causing major pain IMO.
It feels a bit weird though. We are quite fussy about our releases
and now this is meant to be "naaa ...let it be!"?
How much pain was the broken cli jar causing that somehow got onto
the maven repos?
Also I don't know why have to keep the "just drop it in" attitude up
as such a high virtue.
> The lesson should be to not have dependencies between commons
> projects wherever possible.
I still don't buy into the "no dependencies" approach. There is a
difference between compile time and runtime. I do agree that self
contained projects are easier to handle - but that is also possible
with tools (as said before). Did I say that I hate duplicate
code? ...that's why I am here at Commons.
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [beanutils] commons collection classes
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Torsten Curdt wrote:
> On 18.05.2007, at 21:56, Thorbjørn Ravn Andersen wrote:
>> I suggest marking the offending methods as deprecated for the 1.x
>> series, and schedule them for removal in the 2.x series.
>
> Well, then let's create a 2.x branch and do a release without the
> classes *now*. No problem with that. Then it is communicated and people
> can choose. But doing *nothing* just because of binary compatibility is
> silly.
Doing nothing because of binary incompatibility is not silly, its
essential. Commons has to be far more extreme than almost any other OSS
project on this point.
In fact, I contend that commons is now in such a position that we can't
make incompatible changes even in major version number releases.
> Especially as no one *has* to upgrade libraries. And checking
> release notes if you do can't hurt if you upgrade.
Users are forced to upgrade all the time, and thats why they require
backwards compatibility.
For example, if project A is complied against the old [beanutils] jar,
while project B is compiled against the new [beanutils] jar, then it is
impossible to use both project A and project B together. You cannot
physically upgrade the jar file to the one B needs, because A needs the
old one.
The only solutions to this at present are
- for the 2.x series to have a different package name, including 'v2'
- to force the user to play with class loaders, so they can load two
different versions of the same class
In summary, I suggest we all just let this one be. This isn't causing
major pain IMO. The lesson should be to not have dependencies between
commons projects wherever possible.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [beanutils] commons collection classes
Posted by Torsten Curdt <tc...@apache.org>.
On 18.05.2007, at 21:56, Thorbjørn Ravn Andersen wrote:
> Stephen Colebourne skrev den 18-05-2007 18:37:
>>
>> Changing the package name would have been, and still is, backwards
>> incompatible. As such it is unacceptable for such a widely used
>> package as [beanutils]. I am -1 to arbitrarily changing the
>> package name.
>>
>> We really need a prime directive in commons. Don't break backwards
>> compatibility. Every time we do we cause problems down the line -
>> its simple due to our status as the lowest of low libraries. And
>> again, this also emphasises that each commons library works much
>> better when it stands alone - no dependencies.
> I agree that it is important, actually crucial. People trust in
> these modules, and _if_ they break something when upgrading it is
> very prominently displayed on the download page etc. I think it
> would be a bad idea to deliberatly introduce such things.
>
> I suggest marking the offending methods as deprecated for the 1.x
> series, and schedule them for removal in the 2.x series.
Well, then let's create a 2.x branch and do a release without the
classes *now*. No problem with that. Then it is communicated and
people can choose. But doing *nothing* just because of binary
compatibility is silly. Especially as no one *has* to upgrade
libraries. And checking release notes if you do can't hurt if you
upgrade.
Just let's get rid of this mess.
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [beanutils] commons collection classes
Posted by Thorbjørn Ravn Andersen <th...@gmail.com>.
Stephen Colebourne skrev den 18-05-2007 18:37:
>
> Changing the package name would have been, and still is, backwards
> incompatible. As such it is unacceptable for such a widely used
> package as [beanutils]. I am -1 to arbitrarily changing the package name.
>
> We really need a prime directive in commons. Don't break backwards
> compatibility. Every time we do we cause problems down the line - its
> simple due to our status as the lowest of low libraries. And again,
> this also emphasises that each commons library works much better when
> it stands alone - no dependencies.
I agree that it is important, actually crucial. People trust in these
modules, and _if_ they break something when upgrading it is very
prominently displayed on the download page etc. I think it would be a
bad idea to deliberatly introduce such things.
I suggest marking the offending methods as deprecated for the 1.x
series, and schedule them for removal in the 2.x series.
--
Thorbjørn
Re: [beanutils] commons collection classes
Posted by James Carman <ja...@carmanconsulting.com>.
Leaving this like it is breaks commons-collections, potentially, though. If
beanutils is in the classpath before commons collections (alphabetically it
is, so that is the likely scenario), you'll get the beanutils flavor of
those classes. Not a good idea.
On 5/18/07, Stephen Colebourne <sc...@btopenworld.com> wrote:
>
> Torsten Curdt wrote:
> > On 18.05.2007, at 13:57, Niall Pemberton wrote:
> >> I wasn't part of the decision at the time, but (at least some if not
> >> all) these classes are in the BeanUtils public API so changing the
> >> package would have (and still will) broken binary compatibility (to
> >> remove the dependency on Collections 'coz of its incompatibility
> >> between versions!) - they were copied and (AFAIK) the parts of the
> >> public API deprecated with the intention of removing them in the next
> >> release - but there hasn't been one since that was done and 1.7.0
> >> released.
> >
> > I am not pointing fingers. But whatever it takes - having those classes
> > in there like this is not acceptable and needs to be fixed ASAP.
>
> Whilst it may have frustrated you recently, the current situation really
> isn't that bad. It allowed [beanutils] to drop a 500Kb dependency on
> [collections] in a simple manner.
>
> The copy was permitted as there were few classes involved, and they were
> very stable.
>
> Changing the package name would have been, and still is, backwards
> incompatible. As such it is unacceptable for such a widely used package
> as [beanutils]. I am -1 to arbitrarily changing the package name.
>
> We really need a prime directive in commons. Don't break backwards
> compatibility. Every time we do we cause problems down the line - its
> simple due to our status as the lowest of low libraries. And again, this
> also emphasises that each commons library works much better when it
> stands alone - no dependencies.
>
> In summary, I am currently -1 to any change here, except possibly
> producing a commons-beanutils-without-collections.jar file, perhaps as a
> 1.7.1.
>
> Stephen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [beanutils] commons collection classes
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Torsten Curdt wrote:
> On 18.05.2007, at 13:57, Niall Pemberton wrote:
>> I wasn't part of the decision at the time, but (at least some if not
>> all) these classes are in the BeanUtils public API so changing the
>> package would have (and still will) broken binary compatibility (to
>> remove the dependency on Collections 'coz of its incompatibility
>> between versions!) - they were copied and (AFAIK) the parts of the
>> public API deprecated with the intention of removing them in the next
>> release - but there hasn't been one since that was done and 1.7.0
>> released.
>
> I am not pointing fingers. But whatever it takes - having those classes
> in there like this is not acceptable and needs to be fixed ASAP.
Whilst it may have frustrated you recently, the current situation really
isn't that bad. It allowed [beanutils] to drop a 500Kb dependency on
[collections] in a simple manner.
The copy was permitted as there were few classes involved, and they were
very stable.
Changing the package name would have been, and still is, backwards
incompatible. As such it is unacceptable for such a widely used package
as [beanutils]. I am -1 to arbitrarily changing the package name.
We really need a prime directive in commons. Don't break backwards
compatibility. Every time we do we cause problems down the line - its
simple due to our status as the lowest of low libraries. And again, this
also emphasises that each commons library works much better when it
stands alone - no dependencies.
In summary, I am currently -1 to any change here, except possibly
producing a commons-beanutils-without-collections.jar file, perhaps as a
1.7.1.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [beanutils] commons collection classes
Posted by Niall Pemberton <ni...@gmail.com>.
On 5/18/07, Torsten Curdt <tc...@apache.org> wrote:
> On 18.05.2007, at 13:57, Niall Pemberton wrote:
>
> > I wasn't part of the decision at the time, but (at least some if not
> > all) these classes are in the BeanUtils public API so changing the
> > package would have (and still will) broken binary compatibility (to
> > remove the dependency on Collections 'coz of its incompatibility
> > between versions!) - they were copied and (AFAIK) the parts of the
> > public API deprecated with the intention of removing them in the next
> > release - but there hasn't been one since that was done and 1.7.0
> > released.
>
> I am not pointing fingers. But whatever it takes - having those
> classes in there like this is not acceptable and needs to be fixed ASAP.
Needs to be fixed in Digester too/first:
http://issues.apache.org/jira/browse/DIGESTER-115
Niall
> cheers
> --
> Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [beanutils] commons collection classes
Posted by Niall Pemberton <ni...@gmail.com>.
On 5/18/07, Niall Pemberton <ni...@gmail.com> wrote:
> On 5/18/07, Torsten Curdt <tc...@apache.org> wrote:
> > On 18.05.2007, at 13:57, Niall Pemberton wrote:
> >
> > > I wasn't part of the decision at the time, but (at least some if not
> > > all) these classes are in the BeanUtils public API so changing the
> > > package would have (and still will) broken binary compatibility (to
> > > remove the dependency on Collections 'coz of its incompatibility
> > > between versions!) - they were copied and (AFAIK) the parts of the
> > > public API deprecated with the intention of removing them in the next
> > > release - but there hasn't been one since that was done and 1.7.0
> > > released.
> >
> > I am not pointing fingers. But whatever it takes - having those
> > classes in there like this is not acceptable and needs to be fixed ASAP.
>
> I've created a Jira ticket for this and attached a patch which shows
> where the copied classes are used - its actually only FastHashMap.
> Some changes have zero impact, so I'll apply those parts. Then its a
> case of deciding what to do - IMO we should just delete the 3 unused
> classes. FastHashMap could either be removed or re-packaged. When I
> have time I'll have a look at the impact on Struts - since I think
> thats probably the reason for the 3 unused classes.
Forgot the link to the Jira ticket:
https://issues.apache.org/jira/browse/BEANUTILS-278
> Niall
>
> > cheers
> > --
> > Torsten
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [beanutils] commons collection classes
Posted by Niall Pemberton <ni...@gmail.com>.
On 5/18/07, Torsten Curdt <tc...@apache.org> wrote:
> On 18.05.2007, at 13:57, Niall Pemberton wrote:
>
> > I wasn't part of the decision at the time, but (at least some if not
> > all) these classes are in the BeanUtils public API so changing the
> > package would have (and still will) broken binary compatibility (to
> > remove the dependency on Collections 'coz of its incompatibility
> > between versions!) - they were copied and (AFAIK) the parts of the
> > public API deprecated with the intention of removing them in the next
> > release - but there hasn't been one since that was done and 1.7.0
> > released.
>
> I am not pointing fingers. But whatever it takes - having those
> classes in there like this is not acceptable and needs to be fixed ASAP.
I've created a Jira ticket for this and attached a patch which shows
where the copied classes are used - its actually only FastHashMap.
Some changes have zero impact, so I'll apply those parts. Then its a
case of deciding what to do - IMO we should just delete the 3 unused
classes. FastHashMap could either be removed or re-packaged. When I
have time I'll have a look at the impact on Struts - since I think
thats probably the reason for the 3 unused classes.
Niall
> cheers
> --
> Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [beanutils] commons collection classes
Posted by Torsten Curdt <tc...@apache.org>.
On 18.05.2007, at 13:57, Niall Pemberton wrote:
> I wasn't part of the decision at the time, but (at least some if not
> all) these classes are in the BeanUtils public API so changing the
> package would have (and still will) broken binary compatibility (to
> remove the dependency on Collections 'coz of its incompatibility
> between versions!) - they were copied and (AFAIK) the parts of the
> public API deprecated with the intention of removing them in the next
> release - but there hasn't been one since that was done and 1.7.0
> released.
I am not pointing fingers. But whatever it takes - having those
classes in there like this is not acceptable and needs to be fixed ASAP.
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [beanutils] commons collection classes
Posted by Niall Pemberton <ni...@gmail.com>.
I wasn't part of the decision at the time, but (at least some if not
all) these classes are in the BeanUtils public API so changing the
package would have (and still will) broken binary compatibility (to
remove the dependency on Collections 'coz of its incompatibility
between versions!) - they were copied and (AFAIK) the parts of the
public API deprecated with the intention of removing them in the next
release - but there hasn't been one since that was done and 1.7.0
released.
Niall
On 5/18/07, Torsten Curdt <tc...@apache.org> wrote:
> Yepp! We should change the package name and push out a new release.
>
> cheers
> --
> Torsten
>
> On 18.05.2007, at 13:10, James Carman wrote:
>
> > The real question is why didn't we change the package names so as
> > to not
> > collide with the real classes if you have them in your classpath
> > also. I
> > realize that it was required by the public API, but I think having
> > people
> > change an import statement here and there would be accepted more
> > readily
> > than having them chase down a classloading issue where they're
> > using the
> > Buffer impl in the beanutils jar rather than collections jar.
> >
> > On 5/18/07, Niall Pemberton <ni...@gmail.com> wrote:
> >>
> >> On 5/18/07, Torsten Curdt <tc...@apache.org> wrote:
> >> > Grrrr... why oh why are commmons collection classes inside
> >> beanutils?!
> >>
> >> http://tinyurl.com/yvma2q
> >> http://tinyurl.com/2hs3hp
> >>
> >> Niall
> >>
> >> > @!@#$@
> >> > --
> >> > Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [beanutils] commons collection classes
Posted by Torsten Curdt <tc...@apache.org>.
Yepp! We should change the package name and push out a new release.
cheers
--
Torsten
On 18.05.2007, at 13:10, James Carman wrote:
> The real question is why didn't we change the package names so as
> to not
> collide with the real classes if you have them in your classpath
> also. I
> realize that it was required by the public API, but I think having
> people
> change an import statement here and there would be accepted more
> readily
> than having them chase down a classloading issue where they're
> using the
> Buffer impl in the beanutils jar rather than collections jar.
>
> On 5/18/07, Niall Pemberton <ni...@gmail.com> wrote:
>>
>> On 5/18/07, Torsten Curdt <tc...@apache.org> wrote:
>> > Grrrr... why oh why are commmons collection classes inside
>> beanutils?!
>>
>> http://tinyurl.com/yvma2q
>> http://tinyurl.com/2hs3hp
>>
>> Niall
>>
>> > @!@#$@
>> > --
>> > Torsten
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [beanutils] commons collection classes
Posted by James Carman <ja...@carmanconsulting.com>.
The real question is why didn't we change the package names so as to not
collide with the real classes if you have them in your classpath also. I
realize that it was required by the public API, but I think having people
change an import statement here and there would be accepted more readily
than having them chase down a classloading issue where they're using the
Buffer impl in the beanutils jar rather than collections jar.
On 5/18/07, Niall Pemberton <ni...@gmail.com> wrote:
>
> On 5/18/07, Torsten Curdt <tc...@apache.org> wrote:
> > Grrrr... why oh why are commmons collection classes inside beanutils?!
>
> http://tinyurl.com/yvma2q
> http://tinyurl.com/2hs3hp
>
> Niall
>
> > @!@#$@
> > --
> > Torsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [beanutils] commons collection classes
Posted by Niall Pemberton <ni...@gmail.com>.
On 5/18/07, Torsten Curdt <tc...@apache.org> wrote:
> Grrrr... why oh why are commmons collection classes inside beanutils?!
http://tinyurl.com/yvma2q
http://tinyurl.com/2hs3hp
Niall
> @!@#$@
> --
> Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org