We just came over this issue on our CI server, which executed the tests in a different order (Linux filesystem order), compared to our local workstation execution W7 filesystem order.

The case comes from an incorrrect lookup af arguments from placeholders of final and unknown classes.

The use of ArgumentsFactory.createArgumentPlaceholderForUnknownClass assumes if a constructor with a string or numeric value is located, that the equals - relation will return false. This is, unfortunately not the case. Consider the following case in jodatime:

assertEquals(new LocalDate(Integer.MIN_VALUE),new LocalDate(Integer.MIN_VALUE+1));

This actually asserts that the two instances are equal, but the assumption in the code is a unique mapping from argument to invocation-sequence, and in this case, the wrong sequence is returned. I believe the assumption that it i safe to create a safe placeholder using this approach is flawed and should be replaced, possibly with a pluggable factory of placeholder-creators for all unknown classes.

Alternatively, you could add verification-step for unknown classes that verifies that two instances created with placeholder-argument Integer.MIN_VALUE and Integer.MIN_VALUE +1, and fail with an IllegalArgumentExeption if these two placeholders are equal. In this case a pluggable placeholderfactory may be provided.

The first test-case depends on Joda time, but I have also provided a version with the same property regarding the equals reelation that does not depend on Jodatime.

Unfortunately, because of this, we have to restrict lambdaj as a test-only dependency, because we consider it to be unsafe in production.

Starting from lambdaj 2.4 it will be available the static method:

ArgumentsFactory.registerFinalClassArgumentCreator(Class clazz, FinalClassArgumentCreator creator)

where FinalClassArgumentCreator is defined as:

public interface FinalClassArgumentCreator { T createArgumentPlaceHolder(int seed); }