On 5/18/07, Torsten Curdt <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
