Below are troubleshooting steps — problems and solutions — for common issues encountered during the migration to JDK11 with Rhino DUs.
JAXB Issues
JAXB library missing
Exception in thread "main" java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException at somewhere.in.your.Code Caused by: java.lang.ClassNotFoundException: javax.xml.bind.JAXBException at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:185) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496) ... 1 more
This means the code cannot see the JAXB library DU. You will need to set up a library ref from your SLEE component to the supplied library
LibraryID[name=jaxb-runtime-glassfish,vendor=org.glassfish.jaxb,version=2.4.0-b2]
The JAXB API and other runtime dependencies will be visible transitively.
Classloader issues with JAXB unmarshalling
Classloader is not visible.
Caused by: java.lang.ClassNotFoundException: com.sun.xml.bind.v2.ContextFactory at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:471) at com.opencloud.util.MultiparentClassLoader.findClass(MultiparentClassLoader.java:305) at com.opencloud.util.MultiparentClassLoader.loadClassNoResolve(MultiparentClassLoader.java:187) at com.opencloud.util.MultiparentClassLoader.loadClass(MultiparentClassLoader.java:205) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) at java.base/java.lang.Class.forName0(Native Method) at java.base/java.lang.Class.forName(Class.java:315) at javax.xml.bind.ServiceLoaderUtil.nullSafeLoadClass(ServiceLoaderUtil.java:120) at javax.xml.bind.ServiceLoaderUtil.safeLoadClass(ServiceLoaderUtil.java:155) at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:267)
Code to create a JAXBContext for deserialisation may need to be created using a Classloader that has visibility of the JAXB library. Use the classloader aware variant of the JAXBContext factory method.
Use JAXBContext.newInstance(String contextPath, Classloader classloader) over JAXBContext.newInstance(Class… classesToBeBound)
- c = JAXBContext.newInstance(type); + c = JAXBContext.newInstance(type.getPackageName(), type.getClassLoader());
The classloader associated with the class containing the code should work.
Guava Issues
Guava has been upgraded to resolve some issues. There are several API changes, common issues include:
Objects.toStringHelper()
[oc-javac] /some/where/in/my/Code.java:46: error: cannot find symbol
[oc-javac] return Objects.toStringHelper("ZhRequest")
[oc-javac] ^
[oc-javac] symbol: method toStringHelper(String)
[oc-javac] location: class Objects
Guava moved this function to MoreObjects, update code to use MoreObjects.toStringHelper()
- import com.google.common.base.Objects; + import com.google.common.base.MoreObjects;
@Override
public String toString() {
- return Objects.toStringHelper("Code")
+ return MoreObjects.toStringHelper("Code")
Iterators.emptyIterator()
[oc-javac] /somewhere/in/your/Code.java:71: error: <T>emptyIterator() is not public in Iterators; cannot be accessed from outside package [oc-javac] when(empty.iterator()).thenReturn(Iterators.<CassandraRow>emptyIterator()); [oc-javac] ^ [oc-javac] where T is a type-variable: [oc-javac] T extends Object declared in method <T>emptyIterator()
Use Collections.<T>emptyIterator()
Misc Issues
Problems with Javadoc validation
Fix the javadoc. More recent versions of Java are stricter with validation.
Commonly seen tag problems are:
-
@linkused when class is inaccessible. Suggest changing to@codeas previously it would not have worked. -
@returnused for void methods. Can be solved by removing tag. -
Mismatched
{}. Can be solved by adding missing brackets.
Another common problem is the source set being incorrect meaning javadoc cannot find the required classes. This can usually be fixed by either moving the files to where javadoc is looking, or telling javadoc to look somewhere else.
JDK11 FilePermission change
At deployment or at runtime,
java.security.AccessControlException: access denied ("java.io.FilePermission" "xxxxx" "read")
From OpenJDK9: it removes pathname canonicalization from FilePermission creation, thus calculations of the equals() and implies() methods will be based on the raw path string one provides in "new FilePermission(path, action)". details: http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-October/005062.html
By default Rhino startup scripts use -Djdk.io.permissionsUseCanonicalPath=true to work around this behaviour.
JRE removal from JDK11
JRE is removed from JDK11, paths originally with jre will be broken.
Some paths wll need updating, for example, path jre/lib/security/cacerts will be lib/security/cacerts
Guice has moved
[ivy:resolve] :::::::::::::::::::::::::::::::::::::::::::::: [ivy:resolve] :: UNRESOLVED DEPENDENCIES :: [ivy:resolve] :::::::::::::::::::::::::::::::::::::::::::::: [ivy:resolve] :: com.google#guice;4.2.2: not found [ivy:resolve] :::::::::::::::::::::::::::::::::::::::::::::: [ivy:resolve]
Organisation name has changed, need to update ivy dependency
manually:
- <dependency org="com.google" name="guice" rev="${guice.ivy.revision}" conf="self,impl -> war,util" />
+ <dependency org="com.google.inject" name="guice" rev="${guice.ivy.revision}" conf="self,impl -> war,util" />
OR automatically for a whole repo:
find . -name ivy.xml -exec grep 'dependency.*org="com.google".*name="guice"' {} \; \
-exec sed --in-place '/dependency.*name="guice"/s/org="com.google"/org="com.google.inject"/' {} \; \
-exec grep 'dependency.*name="guice"' {} \; -print
Log4j has moved
[ivy:resolve] :::::::::::::::::::::::::::::::::::::::::::::: [ivy:resolve] :: UNRESOLVED DEPENDENCIES :: [ivy:resolve] :::::::::::::::::::::::::::::::::::::::::::::: [ivy:resolve] :: apache#log4j;2.11.2: not found [ivy:resolve] :::::::::::::::::::::::::::::::::::::::::::::: [ivy:resolve]
manually:
- <dependency org="apache" name="log4j" rev="${log4j.ivy.revision}" conf="self -> api" />
+ <dependency org="org.apache.logging.log4j" name="log4j" rev="${log4j.ivy.revision}" conf="self -> api" />
OR automatically for a whole repo:
find . -name ivy.xml -exec grep 'dependency.*org="apache".*name="log4j"' {} \; \
-exec sed --in-place '/dependency.*name="log4j"/s/org="apache"/org="org.apache.logging.log4j"/' {} \; \
-exec grep 'dependency.*name="log4j"' {} \; -print
SLF4J 1.7.25 works differently with log4j 2.11.2
[junit] Failed to instantiate SLF4J LoggerFactory [junit] Caused an ERROR [junit] Reported exception: [junit] org/apache/log4j/Level [junit] java.lang.NoClassDefFoundError: org/apache/log4j/Level
Change the conf for slf4j from log4j to log4j-bridge thus
manually:
- <dependency org="org.slf4j" name="slf4j" rev="${slf4j.ivy.revision}" conf="self -> api,log4j" />
+ <dependency org="org.slf4j" name="slf4j" rev="${slf4j.ivy.revision}" conf="self -> api,log4j-bridge" />
OR automatically for a whole repo:
find . -name ivy.xml -exec grep 'dependency.*org="org.slf4j".*name="slf4j".*conf=".*log4j' {} \; \
-exec sed -E --in-place '/dependency.*name="slf4j"/s/conf="([^"]+)log4j([";,])/conf="\1log4j-bridge\2/' {} \; \
-exec grep 'dependency.*name="slf4j"' {} \; -print
Local Name Service Common Module Removed
Local-Name-Service was a common module that could be used to specify host names that should resolve to the loopback address in a system property (com.opencloud.localnameservice.names). It was heavily dependent on a package in the JDK called sun.net.spi.nameservice, which was removed in JDK9 and there does not appear to be a library to re-add it. Fortunately there is a new built in system property that can be used to achieve the same effect: jdk.net.hosts.file. The structure of this file is equivalent to that of the /etc/hosts file.
