Apache commons-configuration library has wrong transitive dependencies

Jun 15 2011

Latest version of Apache commons-configuration library is 1.6 and depends on commons-beanutils-core 1.8.0 and on commons-digester 1.8 , so dependency tree looks like :

commons-configuration:commons-configuration:jar:1.6:compile
+- commons-digester:commons-digester:jar:1.8:compile
|  \- commons-beanutils:commons-beanutils:jar:1.7.0:compile
\- commons-beanutils:commons-beanutils-core:jar:1.8.0:compile

What’s pretty funny :

One of the ways to fix this – exclude commons-beanutils-core from commons-configuration and enforce that only commons-beanutils used :

<dependencies>
  <dependency>
    <groupId>commons-configuration</groupId>
    <artifactId>commons-configuration</artifactId>
    <version>1.6</version>
    <exclusions>
      <exclusion>
        <groupId>commons-beanutils</groupId>
        <artifactId>commons-beanutils-core</artifactId>
      </exclusion>
    </exclusions>
  </dependency>
</dependencies>

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-enforcer-plugin</artifactId>
      <version>1.0</version>
      <executions>
        <execution>
          <id>enforce-banned-dependencies</id>
          <goals>
            <goal>enforce</goal>
          </goals>
          <configuration>
            <rules>
              <bannedDependencies>
                <message>commons-beanutils:commons-beanutils should be used instead</message>
                <excludes>
                  <exclude>commons-beanutils:commons-beanutils-core</exclude>
                </excludes>
                <searchTransitive>true</searchTransitive>
              </bannedDependencies>
            </rules>
          </configuration>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

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.

Game "predict behaviour" with Apache commons-configuration library

Apr 29 2011

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 :

import org.apache.commons.configuration.Configuration;
import org.apache.commons.configuration.BaseConfiguration;
import java.util.Arrays;

public class Example {
  public static void main(String[] args) {
    Configuration configuration = new BaseConfiguration();
    configuration.setProperty("key1", " value ");
    configuration.setProperty("key2", " value1 , value2 ");

    System.out.println("'" + configuration.getString("key1") + "'");
    System.out.println("'" + configuration.getString("key2") + "'");
    System.out.println(Arrays.toString(configuration.getStringArray("key1")));
    System.out.println(Arrays.toString(configuration.getStringArray("key2")));
  }
}

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 '
'value1'
[ value ]
[value1, value2]

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.

Have fun!