After migrating to angus. How to analyze the java.lang.NoClassDefFoundError: javax/activation/DataContentHandler

[skin27]

I have an application that is currently Java8/OSGi, and I migrated to Java 21/Spring Boot. Basically everything works now, but I still have an issue with mail.

This is my old dependency:

<dependency>
    <groupId>com.sun.mail</groupId>
    <artifactId>javax.mail</artifactId>
    <version>${javax-mail-version}</version>
    <exclusions>
        <!-- javax activation is part of the JDK now -->
        <exclusion>
            <groupId>javax.activation</groupId>
            <artifactId>activation</artifactId>
        </exclusion>
    </exclusions>
</dependency>

And this is my new dependency:

 <!-- https://mvnrepository.com/artifact/org.eclipse.angus/angus-mail -->
<dependency>
    <groupId>org.eclipse.angus</groupId>
    <artifactId>angus-mail</artifactId>
    <version>2.0.3</version>
</dependency>

I ran this locally, and it worked, but when I used Jib to put the application on a Docker image, I get the following:

java.lang.NoClassDefFoundError: javax/activation/DataContentHandler
	at java.base/java.lang.ClassLoader.defineClass1(Native Method)
	at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1027)
	at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
	at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
	at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
	at java.base/java.lang.ClassLoader.defineClass1(Native Method)
	at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1027)
	at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
	at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
	at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
	at jakarta.activation.MailcapCommandMap.getDataContentHandler(MailcapCommandMap.java:594)
	at jakarta.activation.MailcapCommandMap.createDataContentHandler(MailcapCommandMap.java:572)
	at jakarta.activation.CommandMap.createDataContentHandler(CommandMap.java:205)
	at jakarta.activation.DataHandler.getDataContentHandler(DataHandler.java:587)
	at jakarta.activation.DataHandler.getContent(DataHandler.java:514)
	at jakarta.mail.internet.MimeMessage.getContent(MimeMessage.java:1504)
	at org.assimbly.mail.component.mail.MailBinding.extractBodyFromMail(MailBinding.java:302)
	at org.assimbly.mail.component.mail.MailMessage.createBody(MailMessage.java:93)
	at org.apache.camel.support.MessageSupport.getBody(MessageSupport.java:68)
	at org.assimbly.mail.component.mail.MailConsumer.createExchange(MailConsumer.java:406)
	at org.assimbly.mail.component.mail.MailConsumer.retrieveMessages(MailConsumer.java:328)
	at org.assimbly.mail.component.mail.MailConsumer.poll(MailConsumer.java:164)
	at org.apache.camel.support.ScheduledPollConsumer.doRun(ScheduledPollConsumer.java:205)
	at org.apache.camel.support.ScheduledPollConsumer.run(ScheduledPollConsumer.java:119)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
	at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:358)
	at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
	at java.base/java.lang.Thread.run(Thread.java:1583)
Caused by: java.lang.ClassNotFoundException: javax.activation.DataContentHandler
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
	... 38 common frames omitted

Thus at the moment it's calling:

at jakarta.mail.internet.MimeMessage.getContent(MimeMessage.java:1504)

it throws an error:

Caused by: java.lang.ClassNotFoundException: javax.activation.DataContentHandler

As far as I can tell, there are no leftovers that still use javax. However, apparently there is still a reference to javax that causes the classloading error. This is not a bug in Angus (jakarta-mail), but maybe you help me to better analysis it. How to read the stracktrace?, and is there a method to analyze this issue?

as the jakarta.activation-api is a runtime dependency of Angus I already tried to set it explicitly at compile scope, but that didn't make any difference.

[jmehrens]

Probably a duplicate of jakartaee/mail-api#527. See comments in that ticket.

[skin27]

Yes, this maybe related. In this ticket, one is referencing a solution to create his own DataContentHandler class. If possible, I like to avoid that. I'd also like to avoid old javax on the classpath.

In a new version of angus-mail is everything renamed (including meta-inf), so that this issue isn't possible to occur anymore?

[jmehrens]

The problem is that the legacy code and current code in activation/mail that works like ServiceLoader doesn't check the resolved class name in the text files are assignable in current classloader. It should detect and skip these entries but doesn't.

[skin27]

OK, thanks for the explanation. Besides the improvement of the detection, for me the most important thing would be a clearer error message / stacktrace. If it was clear where the conflict happens, which components are involved, and what steps I can take to solve it, then I could faster solve it on my own. Will a solution be part of the next Angus release?

[jmehrens]

Looking at your pom, you are missing 3 dependencies.

      <dependency>
        <groupId>jakarta.activation</groupId>
        <artifactId>jakarta.activation-api</artifactId>
        <version>2.1.3</version>
      </dependency>
      <dependency>
        <groupId>org.eclipse.angus</groupId>
        <artifactId>angus-activation</artifactId>
        <version>2.0.2</version>
      </dependency>

      <dependency>
        <groupId>jakarta.mail</groupId>
        <artifactId>jakarta.mail-api</artifactId>
        <version>2.1.3</version>
      </dependency>
      <dependency>
        <groupId>org.eclipse.angus</groupId>
        <artifactId>angus-mail</artifactId>
        <version>2.0.3</version>
      </dependency>

JDK9+ doesn't include activation like JDK8. That is the cause of the NCDFE. Since it is looking for old activation, there is an old JavaMail dependency in your project.

The problem with making this easier to debug is that both old and new code bases have to be modified. There are projects with 15 year old JavaMail code. Mixing the versions means old code gets run sometimes.

[skin27]

Yeah, I know. Jakarta mail (Java mail) had its roots in 1998. Over the years it was included in the JDK (around Java 6), then excluded again (Java 9+). And then in 2019 Java EE became Jakarta EE, before the Eclipse foundation moved it to the Angus project in 2021.

Based on Maven Central of the Angus mail dependency:

https://mvnrepository.com/artifact/org.eclipse.angus/angus-mail/2.0.3

I saw that it has a compile time dependency on the jakarta.activation-api and jakarta.mail-api, while a runtime dependency on angus-activation. So I wasn't sure that all the dependencies were needed.

There are a couple of issues that make it hard to debug issues with Javax/Jakarta/Angus mail:

1. Long history of the project so that a lot of versions exist.
2. A lot of renaming of the artifactID and groupID.
3. There are dependency with and without "-api".
4. It's not only about the code, the dependency, but also about the META-INF (providers).
5. Some depedencies (activation) are compile time, and some are runtime.

To be honest, I also already added those dependencies explicitly to the project you mentioned, but that didn't change the error. Even when I forced them with Gradle. The error however provides no clues where and what conflicting is. It see jakarta in the stacktrace, and then out of the blue javax. The only information this provides it that there is conflict somewhere with an older version. What library, and where it is, I didn't know.

The problem however is that the activation library (JAF) is used by many libraries, and sometime as runtime dependency and sometimes as compile time dependency.

I didn't know anything about Java mail and JAF. My task was to migrate an old monolith project from Java 8 to Java 21. This contained lots of Jakarta EE, and 1000+ dependencies (that pulls in other transitive dependencies). I tested the migration locally and all went well, only when deployed onto the server (exploded into a Docker container) the error occurred.

The error states javax, I checked the dependency tree with Gradle. This was rather big (15000 lines), but could find no reference to javax.mail or javax.activation. First when I checked other projects (it's a multi-module/multi-repository project), and checked other names like mail, mailapi, activation-api, com.sun.mail etc, I could find the conflicting dependency.

So I got it working, but during my search finds lots of Stack Overflow and other tickets related to dependency/conflicts regarding Java Mail. This was also to share my experience and hope you can improve it to avoid such errors in the future.

As this seems to be a duplicate, you can close the ticket.

[jmehrens]

Thanks for feedback. If you can get rid of all old references to activation and mail. The error should go away because of no mixing of versions. I'll see what I can do to improve error message.