Performance tests for introspection of JavaBeans

Java has the Introspector class that either uses the Reflection API or explicit information about a bean stored in a BeanInfo object. This class provides a standard way to access the properties of JavaBeans and comes in handy if you’d like to copy properties from one bean to another in a generic way.

Suppose you’ve built an application that uses standard JavaBeans to represent business objects of your problem domain. Then you decided to expose your application as a web service that returns XML: you created a XML Schema for JAXB and generated a second model with it. Now all you would have to do is to fill the generated model and use JAXB to read/write it to your web service.

Since you’re a hacker and avoid repetitive work like the plague you write a tool that introspects your original beans and populates their properties to the generated JAXB beans and vice versa. This way you don’t have to write lots and lots of code that looks like:

// for marshalling
// for unmarshalling

You might ask why you don’t use the generated model in the first place and get rid of the old one. First of all this would be less fun and as a serious answer you probably don’t want to couple your application too tight to JAXB, because you might want to switch to another Java-to-XML binding framework (e.g. Castor) in the future.


I wrote a small class (88 LOC) that’ll copy properties from one bean to another; it uses the aforementioned Introspector class. Although this is a pretty straight forward thing it introduces a major performance penalty.

The final class is now a product of several development cycles:

  1. my first version was a brute force attempt with some for loops
  2. the second version stored the methods of the JavaBeans in a lookup table; so it could look up the methods faster
  3. in addition to the second version, the third version tries to make no duplicate calls to e.g. getClass() – these things are stored in variables now.

You can download the Eclipse project as tar.gz or zip file or browse the code here; make sure that you have the Maven2 plugin for Eclipse installed.


To evaluate the different versions, I coded a simple performance test that compares the performance of my BeanIntrospector implementation to code that does the same thing by hand, i.e. calling every getter/setter of two beans one after another.

The first chart shows a comparison of the different implementations.

Performance comparison for introspection of JavaBeans

This leaves no doubt that the boring solution is by far the fastest. Another thing you can notice is that tuning the code can help a lot: while the first implementation takes more than 100ms to fill 1000 JavaBeans, the tuned version takes about 40ms to do the same thing. In addition to that the final version is more readable than the brute force variant.

The second chart shows a comparison between the final implementation and doing the same thing by hand. Note that I set the y-axis to logarithmic scale.

Performance comparison for introspection of JavaBeans with more runs


If performance is important for your application you should explicitly copy the properties from one bean to another. If you’ve got beans with a lot of properties, write yourself a small tool that’ll generate the code for you. On the other hand if you need a fast hack you might want to use the BeanIntrospector class I wrote or write yourself a similar solution.

3 thoughts on “Performance tests for introspection of JavaBeans”

  1. Hi, facing exactly the same problem (having to write an enormous load of boring code to map from JAXB objects to business DTOs), I found this framework :

    In my own performance tests (real use on the server with logs), i see the mapping (after the first time it encounters a new object wich caches all the methods lookups) is taking 0 ms , whenever I use hand coded mapping or dozer.

    By the way , I figured that for this matter, testing in a big for loop on my dev computer makes no sense, I think I end up testing what my operating system is doing!

    – Could you try your perf test with dozer ?
    – Could you explain your performance tests methodology / provide the test code ?

  2. Hi Simon,

    thank you for the link to Dozer. I’ll check it out and write a (hopefully detailed) post soon.

    I obviously forgot to upload the test code: now you can have a look at it here. Basically it’s a “big for loop” and certainly not the most realistic way to test this, but I think that it gives us a good indication for the one or the other solution – whether this might be faster than that and so on.

    Do you have another idea for a performance test – instead of the “big for loop”?

  3. Pingback: Christian Schenk

Comments are closed.