How I fixed a bug & how a bug is fixed due to Apache

Fixing Apache Bugs: JMeter

Emilian Bold

I’ve been a long time NetBeans user, contributor, and committer. And I jumped right in when I found out that NetBeans will join Apache.

I’ve been a long time NetBeans user, contributor, and committer. And I jumped right in when I found out that NetBeans will join Apache.

Of course, every developer has heard about Apache. But I don’t believe many know how Apache is much more focused on the community.

Since NetBeans started the incubation process under Apache, I see Apache quite differently.

So, this article is mostly about how I fixed a bug but also how a bug is fixed due to Apache.

It all started with me looking the other day for another Apache project that would need better integration with NetBeans. Somehow I ended up being curious about which Apache projects would need help with bug fixing and discovered Apache has a Help Wanted site just for this.

The Help Wanted site is a bit underused but this makes JMeter stand out with half of the tasks!

I knew about JMeter and remembered it has a Java Swing UI that could perhaps integrate well with the NetBeans Platform.

As an excuse to see the codebase, I though I should fix a bug.

JMeter has a nice little issues page where they link to their open bugs so I chose #58743. I picked the issue at random: something that’s also related to the UI so I get to see the JMeter code in that area.

The initial error is a ClassCastException:

java.lang.ClassCastException: org.apache.jmeter.assertions.SubstitutionElement cannot be cast to
after a MultiPropertyConverter.marshal call. So, it initially looked like an XStream serialization problem.

While debugging I saw that an array did end up having the SubstitutionElement and I figured it must be some misconfigured XStream Converter.

Something didn’t add up. Then I noticed that a CollectionProperty value array was actually corrupted in the clone() method. Well, cloning problems are no fun!

But it wasn’t cloning of the ‘value’ array that seemed to cause this, it looked constructor related.

So I found out that only the CollectionProperty constructor that gets a Collection argument seems to have issue. And after much time, that only if the argument was empty!

It was a case of exposed internal data.

CollectionProperty took the collection instance as-is and used it! But who was also using it?

Debugging and logs were not enough so I had to start JVisualVM for some quick BTrace script. Nothing fancy, just enough to see the instance hashcode:

@OnMethod(clazz="+java.util.ArrayList", method="<init>", [email protected](Kind.RETURN))
    public static void createArrayList(@Self java.util.ArrayList self) {
        print("created @");

This is how I finally discovered that CollectionProperty.value and ObjectTableModel.objects were using the same collection instance and they were adding different data to it!

But why was CollectionProperty using that same instance! Due to an optimization in AbstractProperty.normalizeList

        if (coll.isEmpty()) {
            @SuppressWarnings("unchecked") // empty collection, local var is here to allow SuppressWarnings
            Collection<JMeterProperty> okColl = (Collection<JMeterProperty>) coll;
            return okColl;

to reusing empty arrays!

The fix was now obvious: stop reusing the empty arrays.

All the Apache projects are mirrored on GitHub. I did a fork of JMeter, pushed my fix, then created my pull request.

In a few hours the fix was already reviewed by two JMeter members!

It was a hard bug to track down. But I only started working on it because it was another Apache project.


Emilian Bold

Emilian Bold is a Java developer with a decade of experience in rich Swing-based desktop applications, usually based on NetBeans Platform. He has focused the past years on Javascript interoperability via Rhino and recently Nashorn. He is a member of the NetBeans Dream Team and works at his own company Joseki Bold SRL ( ).