Inheritance-Report

At the end of a successful run of the AI engine, a warning message can occur to indicate the existence of inheritance relationships across partitions.

WARN: Partition recommendation contains broken inheritance chain across partitions,
  modifying partition.txt to compensate, merged partitions might have combined names,
  see partition.txt and cardinal_graph.json in Cardinal folder for details.

Inheritance relationships become problematic for partition recommendations because classes that reference one another can be in separate partitions. In this case, the partitions are merged until all of the classes that are related by inheritance are in the same partition. Inheritance relationships based on business logic, natural seams, or custom partitions can result in one or two large partitions that contain many classes.

Sample Inheritance-Report

An Inheritance-Report visually shows a class inheritance hierarchy in a Java monolithic application. The next figure shows an example for a sample application.

In this figure, the Owner class in partition2 inherits from the Person class in partition4, which itself inherits from the BaseEntity class of partition2. The report shows both the breadth and the depth of the inheritance chains as a pair [x:y] displayed next to each class. For any particular class, x represents the depth of the class while y represents its number of direct children in the inheritance hierarchy of the Java monolithic application. In this example, the pair of numbers [2:3] next to the NamedEntity class in partition1 indicates that the NamedEntity class is at depth 2 and that it has three direct children. The children are the Pet, PetType, and Specialty classes.

Use the Filter Unobserved Inheritances and Filter FQCN check boxes to reduce the clutter in viewing the inheritance report. Selecting the Filter Unobserved Inheritances box hides all the classes that belong to the unobserved partition. Selecting the Filter FQCN box suppresses the fully qualified long class names from the report. These filter options help you work with large inheritance reports that are generated from large legacy Java monolithic applications.

Inheritance relationships between classes are dependencies typically result from the sharing of code. The Inheritance-Report includes only proper inheritance, not interfaces nor the corresponding classes that implement them.

Handling inheritance relations

When inheritance dependencies exist across partitions, it might be necessary to change the source code to remove (or "flatten") inheritance relationships between certain classes before it is possible to generate good microservices. You need to flatten the inheritance relationships only between classes that are not collocated in the same partitions as their immediate parents. In the previous figure, all of the depicted inheritance relationships must be flattened because not a single child class is collocated in the partition of its immediate parent. Even though the BaseEntity and Owner classes belong to the partition2 partition, the immediate parent of the Owner class is the Person class in the partition4 partition. This relationship chain requires complete flattening of the inheritance relationship between the BaseEntity, Person, and Owner classes.

Flattening inheritances by introducing proper types in the form of Java interfaces or by delegation is not difficult and is explained in available literature. Some IDEs include features for flattening inheritances with minimal effort. A set of Concise guidelines for flattening inheritance is included in the Reference.

A Java monolithic application where all required inheritance relationships are flattened is conducive to refactoring. To refactor the modified Java monolithic application, you run the entire IBM Mono2Micro process on the modified Java monolithic application, as outlined in IBM Mono2Micro overview. If the required inheritance relationships are successfully flattened, a run of the AI engine produces an empty Inheritance-Report, as shown in the next figure.