What’s pretty funny :
* commons-beanutils 1.7.0 has memory leaks, which were fixed in 1.8.0,
* commons-digester 1.8.1 depends on commons-beanutils 1.8.0,
* but in any case commons-beantuils and commons-beanutils-core - is a kind of duplication - from BeanUtils site : "commons-beanutils - contains everything; commons-beanutils-core - excludes Bean Collections classes".
One of the ways to fix this - exclude commons-beanutils-core from commons-configuration and enforce that only commons-beanutils used :
What all this means for you? Again - you decide ;) But for me (after all troubles with this library) it means that commons-configuration is a dead project and I will never use it as a dependency for my new projects.
Simple question, which sometimes asked on interviews - "what will be printed after execution of following program?"
Let’s ask this question against following program, which is based on commons-configuration library version 1.6 :
Hard to predict output without documention.
So Javadoc for method getString :
Get a string associated with the given configuration key.
ConversionException is thrown if the key maps to an object that is not a String.
And Javadoc for method getStringArray :
Get an array of strings associated with the given configuration key. If the key doesn't map to an existing object an empty array is returned.
ConversionException is thrown if the key maps to an object that is not a String/List of Strings.
Also on project site we can learn that getStringArray is able to split strings using list delimiter character (comma by default).
This is a first surprise for consumers of API of interface Configuration : why this is not mentioned in Javadoc ?
Also we can learn that getString method called for a property with multiple values will return only first one.
Second surprise : why ? And again why not in Javadoc ?
But OK - now based on all this knowledge we can predict following output :
' value '
' value1 '
[ value ]
[ value1 , value2 ]
And boom - actually output will look like :
' value '
[ value ]
Final surprise : some values were trimmed!
If this is done by getStringArray, then why this is not the case for key1 ?
I tried to inspect Javadocs for class hierarchy ( Configuration -> AbstractConfiguration -> BaseConfiguration ), but did not found anything about trimming (and on site too).
So you can find this behaviour only when your application will not work as you expect. Or if you will inspect source code of library.
What all this means for you? You decide ;)
But from my point of view : think twice before adding third-party dependencies into your application. And four times before exposing them in your API.