The June release of IBM® Mono2Micro™ enriches the utility and common code discovery experience with an improved AI that now considers both static code analysis as well as dynamic instrumentation of executed code as use cases are run. Java monolith application classes that tend to have minimal or no state, and/or have mostly static member methods and fields, and/or have mostly incoming method calls as opposed to outgoing, and so on are the kind of classes that the AI identifies in its analysis. Other factors and heuristics are also considered to arrive at the final recommendations.
The utility classes are shown in a special group much like the unobserved classes, and they are also colored to match the regular partition's color that the AI recommends they be placed in if you deem they are not really utility code. For example, the 'KeySequenceDirect' class below has been identified as a utility class, and if you decide it is better for it to be part of a microservice rather than be in a common utility JAR that could be packaged with multiple microservices, then the next best home for it is 'partition3' according to Mono2Micro's AI.
Notice that no observed runtime calls to the utility classes are shown, and this is by design. The workbench UI now gives you the ability to pick and choose which types of runtimes calls and dependencies between classes are shown, and by default Mono2Micro does not show runtimes calls to the utility classes to declutter the UI and help you focus in on the regular partitions and their classes' runtime calls. In the filter panel, you choose which runtime calls or dependencies to show:
For example, when selecting only the "Runtime calls to utility partition" checkbox, Mono2Micro shows just the runtime calls associated with the utility classes, which then gives you a good idea as to how they are widely called from various other classes in various partitions, and therefore making them good candidates for packaging in a utility jar with all the partitions that need them.
When running the 'mono2micro recommend' command, a new option '--exclude-utility-classes' can now be passed to instruct the AI to not consider the utility classes for refactoring consideration. That is, only the other classes are analyzed using the AI's hierarchical clustering techniques to recommend the partitions. The placement of other classes in partitions can possibly be impacted if the utility classes are also in consideration for refactoring, so this option allows you to see what the AI recommends by completely excluding them from its analysis.
In the workbench UI, you can customize which classes are placed in the utility group by moving classes in or out of it just like you can with other partitions and groups. This lets you ultimately decide and refine what your future utility jar consists of for use with the future microservices.
Be sure to read these blogs to check out the new features introduced in the previous releases of Mono2Micro:
22.0.09
22.0.06
22.0.03
To take advantage of all these new capabilities and more, head over to https://ibm.biz/Mono2Micro to download and try Mono2Micro yourself.
#ApplicationModernization#ArtificialIntelligence(AI)#JavaEE#Liberty#ML#mono2micro#monolith#OpenLiberty#WebSphereHybridEdition(WHE)#WebSphereLiberty