AssertJ: generating fluent assertions for Set<A extends B>

I've stumbled on an issue where AssertJ generates the following code in one of the assertion classes:

public S hasItems(interface ItemInterface... items)

This of course doesn't compile.

An example code that causes the problem is as follows:


    public interface EntityInterface {

      Set<? extends ItemInterface> getItems();
    }

    @NoArgsConstructor
    @AllArgsConstructor
    @Data
    @With
    public class EntityA implements EntityInterface {

      private Set<ItemA> items;
    }

    @NoArgsConstructor
    @AllArgsConstructor
    @Data
    @With
    public class EntityA implements EntityInterface {

      private Set<ItemA> items;
    }

    public interface ItemInterface {

      String getName();
    }

    public class ItemA implements ItemInterface {

      public String getName() {
        return "ItemA";
      }
    }

    public class ItemA implements ItemInterface {

      public String getName() {
        return "ItemA";
      }
    }

I've included the minimum example project that causes this error, so it can be seen firsthand. It can be downloaded from filebin

We're using Lombok's @With annotation among other considerations and need to keep the interfaces.

To fix this, I have tried:

Changing the getItems method signature to:

<T extends ItemInterface> Set<T> getItems();

which produces:

public S hasItems(T... items)

however T is not known in the context.

Turning the inteface into a template using:

public interface EntityInterface<T extends ItemInterface>

which didn't make any difference.

Is there a solution that I'm missing?

Solution

As you have observed, the problem is that AssertJ creates AbstractEntityInterfaceAssert class with invalid methods like:

public S hasItems(interface ItemInterface... items) {/*...*/}

I have no practical experience with AssertJ but after some research I came to 2 workarounds where compile-time type safety is preserved (changing EntityInterface.getItems() method to return Set<?> works, but is unacceptable):

Use abstract class which implements the interface, instead of using the interface directly:

public interface ItemInterface {
  String getName();
}

public abstract class AbstractItem implements ItemInterface {
}

public class ItemA extends AbstractItem {
  public String getName() {
    return "ItemA";
  }
}

// ItemB same as ItemA

public interface EntityInterface {
  Set<? extends AbstractItem> getItems();
}

@NoArgsConstructor
@AllArgsConstructor
@Data
@With
public class EntityA implements EntityInterface {
  private Set<ItemA> items;
}

// EntityB same as EntityA, but with Set of ItemB

As can be seen, the only changes compared to your example is that AbstractItem is used as base class instead of implementing ItemInterface in both ItemA and ItemA and EntityInterface.getItems() method is changed to return Set<? extends AbstractItem> instead of Set<? extends ItemInterface>.

With these changes the program compiles correctly and generated AbstractEntityInterfaceAssert class has valid method signatures like:

public S hasItems(AbstractItem... items) { /*...*/ }

The second workaround is to exclude EntityInterface from generation using assertj-assertions-generator-maven-plugin settings:

    <build>
        <plugins>
            <plugin>
                <groupId>org.assertj</groupId>
                <artifactId>assertj-assertions-generator-maven-plugin</artifactId>
                <!-- ... -->
                <configuration>
                    <!-- ... -->
                    <!-- Exclude classes matching the regex from generation -->
                    <excludes>
                        <param>com.example.EntityInterface</param>
                    </excludes>
                </configuration>
            </plugin>
        </plugins>
    </build>

The above configuration prevents generation of AbstractEntityInterfaceAssert.java.

I don't know if any of these workarounds is applicable to your use case and unfortunately I cannot provide a better solution or explanation (is that a bug or a limitation of AspectJ?). The best person for that is Joel Costigliola - the author of AssertJ

Helpful reads: