Debugging properties and common errors

Use this information to help investigate and resolve errors.

Useful debug properties for different packages in Java

Kerberos
-Dsun.security.krb5.debug=true
log4j2
-Dlog4j2.debug -Dlog4j2.simplelogLevel=TRACE
SSL
-Djavax.net.debug=all:verbose

Module building errors

Problem: When you try to compile a module descriptor that is generated for a legacy JAR files by using the jdeps command, the following compilation error might be displayed. The package is known to exist in the legacy JAR files.
javac -cp helloworld.jar helloworld/module-info.java
helloworld/module-info.java:2: error: package is empty or does not exist: com.ibm.demo
    exports com.ibm.demo;
                   ^
1 error
Solution: To compile the module descriptor, use the -patch-module option instead of the -classpath option to resolve the package name. In the following example, helloworld is the new module name that you want to assign the legacy JAR files.
javac -patch-module helloworld=./helloworld.jar helloworld/module-info.java
Problem: When you try to compile a Maven project by using IBM Semeru Runtime Certified Edition for z/TPF, some warning messages that are similar to the following messages are displayed.
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.sun.xml.bind.v2.runtime.reflect.opt.Injector 
(file…/.m2/repository/org/glassfish/jaxb/jaxb-runtime/2.3.0/jaxb-runtime-2.3.0.jar) to method 
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int)
WARNING: Please consider reporting this to the maintainers of com.sun.xml.bind.v2.runtime.reflect.opt.Injector
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
gmake: *** [build] Error 1

Solution: Generally, the Illegal reflective access by... warning messages indicate that the Java™ code being used might be back-level and not migrated to support the Java Platform Module System (JPMS). The key to resolve these types of errors is to identify the highest parent dependency in the dependency tree that can be upgraded to a higher version to resolve the issue.

In the example, search for the highest parent dependency that pulled in the org/glassfish/jaxb/jaxb-runtime/2.3.0/jaxb-runtime-2.3.0.jar file. When you add the following option to your makefile during the Maven project build, the Maven tool can provide a full dependency tree:
MVN_BLD_OPTIONS := -X
The maketpf *.out file contains much information about the Maven project build including the full dependency tree. When the highest parent dependency is determined, search for the public Maven repository to find an appropriate higher version to resolve the issue.