The WebSphere Application Server Migration Tools can be used to analyze the contents of an application and determine what changes are needed to migrate to Liberty, a new version of WebSphere, or a new version of Java, among other migration destinations. The 23.0.0.1 release focuses on the Migration Toolkit for Application Binaries. It brings Jakarta EE 10 migration support to the analysis reports and Liberty feature list generator, as well as some new features for user-defined rules. Download the new release of the migration tools today and give them a try, and stick around for a performance tip at the end of the article!

Information about how to use our tools can be found in the WebSphere Application Server Migration Toolkit documentation. For an overview of the application modernization process, see the Modernizing applications to use WebSphere Liberty learning path.

What are the migration tools?

The Migration Toolkit for Application Binaries (binary scanner) is a command line tool for analyzing application binaries. After scanning the application, it produces a report with configuration information, technologies required by the application, a list of necessary code changes for migration, and a view of the contents within the archive. This report can be generated in multiple formats, and you can use different parameters to filter information that you would like to be included. More information about the binary scanner can be found in the What is the Migration Toolkit for Application Binaries? blog post.

The WebSphere Application Server Migration Toolkit (source scanner) is an Eclipse plugin for analyzing source code directly within your development environment.  The source scanner uses the same set of rules as the binary scanner to flag code changes that will be necessary for your migration. When possible, automatic code changes (quick fixes) are available. More information about the source scanner can be found in the What is the WebSphere Application Migration Toolkit? blog post. 

What’s new in version 23.0.0.1?

Jakarta EE 10

With the Jakarta EE 10 specifications released and many application servers adopting them in beta or GA releases, we’ve added a suite of analysis rules to identify any issues that could affect your application when run with Jakarta EE 10. Specify the --targetJakartaEE=ee10 parameter to your --analyze or --all scans to enable these rules, as well as the rules for any prior Java EE/Jakarta EE versions between your source release and Jakarta EE 10.

--targetJakartaEE=[ee8|ee9|ee10]
	Include rules for migrating to the specified target Jakarta
	Enterprise Edition version. The default for Liberty target
	application server includes the Jakarta EE rules that are applicable
	for the Liberty features used by the application.
	The targetJakartaEE option cannot be used with targetJavaEE. The
	targetJakartaEE ee8 and ee9 options are only supported with the
	targetJava options ibm8, oracle8, or later. The targetJakartaEE ee10
	option is only supported with targetJava options java11 and later.
	The following options are valid:
	* ee8  - Jakarta EE 8
	* ee9  - Jakarta EE 9
	* ee10 - Jakarta EE 10

These rules cover the following Jakarta EE technologies:

• General Jakarta EE 10

• Jakarta XML Binding 4.0

• Jakarta Mail 2.1

• Jakarta Servlet 6.0

• Jakarta Persistence 3.1

• Jakarta XML Web Services 4.0

• Jakarta WebSocket 2.1

• Jakarta Expression Language 5.0

• Jakarta Faces 4.0

• Jakarta Server Pages 3.1

• Contexts and Dependency Injection 4.0

• JSON Binding 3.0

In addition, we’ve enabled Jakarta EE 9 as a source release, so you can scan applications that are already at the Jakarta EE 9 level for any additional changes needed to move to Jakarta EE 10.

--sourceJakartaEE=[ee8|ee9|ee10]
	Include rules for migrating from the specified source Jakarta
	Enterprise Edition version. The source Jakarta EE option is only
	valid for the Liberty source application server. The sourceJakartaEE
	option cannot be used with sourceJavaEE. The following options are
	valid:
	* ee8  - Jakarta EE 8
	* ee9  - Jakarta EE 9
	* ee10 - Jakarta EE 10

We’ve also updated the feature lists created during --generateConfig and --all scans to recommend Jakarta EE 10-compatible Liberty features when targeting Jakarta EE 10. Note that as of publication you’ll need a beta version of Liberty to use Jakarta EE 10 features.

User-defined rules

We’ve added new Boolean logic rule elements, and some additional functionality when scanning XML files. We’ve also enabled XML rules to scan XHTML files--useful for analyzing Jakarta Faces files.

Boolean logic

In 23.0.0.1, we’re introducing two new rule elements which allow you to combine rules: <and> and <or>. 

<or> flags the criteria of all rules defined within it that find a match. This is the same behavior as the existing <detectMultipleCriteria>. Existing rules will still work, and you can still use <detectMultipleCriteria> in new rules, but it is deprecated in favor of <or>, so we recommend new rules switch to using <or> instead.

<and> flags a location in a file only if all rules defined within it flag at least once within the archive. This allows you to flag some criteria only if other criteria are also met.

To control which of these criterion matches actually appear in reports, we updated individual rule elements (<detectClass>, <detectPackage>, and so on) to be able to specify the hideResult=”true” attribute, which will skip adding a match for that specific rule’s criterion to the report. 

Putting this all together, you can create rules that flag more complex scenarios than before. In this example, we’re flagging archives that contain uses of any javax.ws.rs.core classes, but only if they either also contain uses of any javax.ws.rs.ext packages or contain classes with the string literal “application/json”. The matches for the classes containing the literal will not be added to the report.

<rule xmlns="http://websphere.ibm.com/xml/ns/wamt/binary-scanner-rule" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://websphere.ibm.com/xml/ns/wamt/binary-scanner-rule binary-scanner-rule_1_0.xsd" id="DetectJSONB"
    description="Detect JSON-B usage">
    <and flagOnce="true">
        <detectPackage names="javax.ws.rs.core"/>
        <or flagOnce="true">
            <detectPackage names="javax.ws.rs.ext"/>
            <detectStringLiteral hideResult="true">
                 <literal value="application/json"/>
            </detectStringLiteral>
        </or>
    </and>
</rule>

Note that this Boolean logic applies across files, so an individual file doesn’t need to match all criteria of all rules under an <and> to count as a match and appear in the report.

XML scanning improvements

We’ve updated two XML rule elements, <detectElement> and <detectAttribute>, to better help you identify when certain items are missing from XML files.

<detectElement> gets the new rule attribute flagNoRootNode=”true”. which flags XML files that do not have any root node at all. For example, you can flag empty beans.xml files intended to mark archives as CDI archives--we added a rule to do this for Jakarta EE 10 migrations.

<detectAttribute> gets the new rule attribute flagIfAttributeMissing="true", which flags the element specified in the tags rule attribute if it doesn’t have an attribute matching the rule attribute attributeName. 

Finally, we’ve updated the binary scanner to include .xhtml files when scanning for XML rule matches, so existing rules will start flagging matches in those files. If you don’t want your rule to scan .xhtml files, make sure you set <xmlFile pattern> to match the kinds of files you do want to scan.

Binary scanner performance tip

We’ve discovered that the binary scanner gets a boost in performance from running on Java SE 11 or above. In some cases, the result is a reduction in scan time of over 40% compared to the same scan run with Java SE 8. This applies to all versions of the binary scanner--you don’t need to download 23.0.0.1 to get the speed up (but we recommend you do so anyway!) Of course, we still support the binary scanner on Java 6 and above, so don’t worry if you can’t run it on Java 11 just yet.

Go ahead and give the latest release a try. Happy modernizing!

#ApplicationModernization #appmigration #WebSphere #WebSphereLiberty #whatsnew