EJAPP Top 10 countdown: #4 - Badly performing libraries

After skipping the easter weekend to go snowboarding in Chamonix, I'll continue the EJAPP Top 10 countdown with number 4.

Badly performing libraries are a problem that occurs more often than one would expect. This issue is somewhat similar to the incorrect usage of Java EE in that not enough care is taken in selecting and using a certain technology. Some development teams will happily pile JAR after JAR into their WEB-INF/lib directory or into their POM file, :

  • without checking whether that library is really needed (and does not overlap with functionality already offered by other libraries used),
  • without checking whether that library can offer good performance or whether a better performing alternative is available,
  • without reading the documentation to see how it should properly be used, and
  • without defining how the library is going to be used within the application

Examples here are:

Even worse, some development teams will write their own frameworks and libraries where existing ones already exist that offer (nearly) the same functionality and (usually) better performance. Apart from the initial inferior performance, these libraries and frameworks do not evolve as rapidly as existing (free) libraries in terms of performance (and functionality and security and ...). As Linus says: Many eyes make all bugs shallow. Unfortunately, I can't give any examples here as those frameworks are, by definition, proprietary.

In any case, to prevent these kinds of problems, follow these steps when some functionality is needed :

  1. Check libraries already used in the project for the functionality.
  2. Check existing (free) libraries for the functionality.
  3. Only when an existing library cannot be found, implement the functionality yourself. Consider releasing it as free software; the community will benefit and may even offer additional functionality, performance improvements, security fixes, etc.
  4. Verify that the selected library can offer the required performance.
  5. Read the documentation, newsgroups and forums about proper usage of the library.

And only then use an existing library or build your own.

Comments (2)

  1. Xebia Blog - Reply

    July 31, 2007 at 9:13 am

    [...] Discussed are numbers 4-Badly performing libraries. More information about number 4 can be found here. and for number 3-Incorrectly implemented concurrency see; here. [...]

  2. RuntimeException - Reply

    March 29, 2008 at 3:28 am

    Very true!

    One thing that developers take for granted in the standard Java libraries, which can contain many surprises in terms of performance. Date handling being a good example.

    Thanks for the tip on URLEncoder, I am off to write a test case 🙂

Add a Comment