Using Jakarta mail and Javamail in the same runtime

[rickstev]

Not sure where to ask this question, so I'll try here. I have an app that uses components, e.g. Apache Axis, that have a direct dependency on Javamail but I want my own code to advance to Jakarta mail 2.0. Having both in my project pom causes a collision in the com.sun package classes, e.g. SMTPTransport. Are the com.sun packages the same (or compatible) between Jakarta and Javamail jars, i.e. could the Jakarta jar be used for those classes? Can this be resolved and if so, suggestions how to do it?

[lukasj]

Are the com.sun packages the same (or compatible) between Jakarta and Javamail jars..?

Unfortunately no.

Can this be resolved and if so, suggestions how to do it?

I think that if you move what you can to Jakarta (no only Mail) and use Eclipse Transformer "somehow" for the rest, it should work.

To define "somehow" - Eclipse Transformer should be able to do two things - either statically transform bytecode of existing libraries so they are "upgraded" to jakarta package namespace OR it can do so dynamically during runtime. I have no real experience with this (yet) but AFAIK Payara is using this in some way to support both - javax as well as jakarta namespaces at the same time

[rickstev]

Thanks lukasj. It seems like when they changed the package names for the javax.mail.* classes they should have done essentially the same thing for the com.sun.* classes. That would have provided a larger application a better path to Jakarta mail 2.0+. For example Apache Axis has dependencies on javax.mail code for MimeBodyParts etc. And if I want my code to use Jakarta mail (for actual mail) and let Axis keep using javax.mail, I only have questionable paths to do so.

[jmehrens]

The jakartaee-platform-dev mentions the following:

From: Mark Thomas markt@apache.org
Date: Thu, Feb 18, 2021 at 2:28 PM
Subject: [ANN] Apache Tomcat Migration tool for Jakarta EE 0.2.0
To: Tomcat Users List users@tomcat.apache.org
Cc: Tomcat Developers List dev@tomcat.apache.org, announce@tomcat.apache.org, announce@apache.org

The Apache Tomcat team announces the immediate availability of Apache
Tomcat Migration Tool for Jakarta EE 0.2.0

Apache Tomcat Migration Tool for Jakarta EE is an open source software
tool for migrating binary web applications (WAR files) and other binary
artefacts from Java EE 8 to Jakarta EE 9.

The notable changes since 0.1.0 include:

• Various fixes to the packages that are and are not converted

• A new option to process zip archives in memory to support zip files
  that use options that are incompatible with a streaming approach

• A new option to exclude files from transformation

Please refer to the change log for the complete list of changes:
https://github.com/apache/tomcat-jakartaee-migration/blob/master/CHANGES.md

Downloads:
http://tomcat.apache.org/download-migration.cgi

Enjoy!

• The Apache Tomcat team

[lrozenblyum]

Since angus-mail:2.* doesn't use the com.sun packages, there are good chances it finally will be able to co-exist with javax.mail without hard hacks.
See https://eclipse-ee4j.github.io/angus-mail/

[lukasj]

as of v. 2.1 of the spec, jakarta.mail-api-2.1.2 with angus-mail-2.0.2 can coexist with old javax based JavaMail versions

[jodastephen]

as of v. 2.1 of the spec, jakarta.mail-api-2.1.2 with angus-mail-2.0.2 can coexist with old javax based JavaMail versions

In my testing this doesn't seem to work. The class MailcapCommandMap loads all resource files named META-INF/mailcap to create a DB hashmap. Because both jars are on the classpath this loads both the com.sun and org.eclipse.angus handlers. This then results in a ClassCastException:

java.lang.ClassCastException: org.eclipse.angus.mail.handlers.text_plain cannot be cast to javax.activation.DataContentHandler
	at javax.activation.MailcapCommandMap.getDataContentHandler(MailcapCommandMap.java:588)
	at javax.activation.MailcapCommandMap.createDataContentHandler(MailcapCommandMap.java:542)
	at javax.activation.DataHandler.getDataContentHandler(DataHandler.java:618)
	at javax.activation.DataHandler.writeTo(DataHandler.java:316)
	at javax.mail.internet.MimeUtility.getEncoding(MimeUtility.java:340)
	at javax.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1575)
	at javax.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1172)
	at javax.mail.internet.MimeMultipart.updateHeaders(MimeMultipart.java:522)
	at javax.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1533)
	at javax.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1172)
	at javax.mail.internet.MimeMultipart.updateHeaders(MimeMultipart.java:522)
	at javax.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1533)
	at javax.mail.internet.MimeMessage.updateHeaders(MimeMessage.java:2271)
	at javax.mail.internet.MimeMessage.saveChanges(MimeMessage.java:2231)
	at javax.mail.internet.MimeMessage.writeTo(MimeMessage.java:1910)
	at javax.mail.internet.MimeMessage.writeTo(MimeMessage.java:1887)
...

Am I doing something wrong?

      <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>

    <dependency>
      <groupId>com.sun.activation</groupId>
      <artifactId>javax.activation</artifactId>
      <version>1.2.0</version>
    </dependency>
    <dependency>
      <groupId>com.sun.mail</groupId>
      <artifactId>javax.mail</artifactId>
      <version>1.6.2</version>
    </dependency>

[jmehrens]

@jodastephen instead of 1.6.2 you can try 1.6.7. However, this looks like a bug. I've had it on my todo list to update all of the calls to Class.forName or ClassLoader.load to skip unusable classes in the 4 projects for mail.

That will mostly fix the problem but we'll have to backport the change to the v1.x branch of mail and create a new 1.6.8 release. Changing the file names we look for in the 2.x branch would avoid clashing with older 1.x releases.

[jodastephen]

v1.6.7 of mail and v2.0.2 of activation make no difference.

Wouldn't it be best to load all resources named META-INF/mailcap2 instead of META-INF/mailcap in the latest release? Or would that be backwards incompatible.

[jmehrens]

Ok. I agree. Changing the file name aligns with my last point. We should be okay to change the name because we are planning to bump to a new spec. We can then document it in compatibility notes. I'll create new tickets to capture the changes. It will be a bit before I get to work on them.

[jmehrens]

@jodastephen Created eclipse-ee4j/angus-mail#151 to capture the renaming of resources.

[NicoPrenzel]

@jmehrens We've faced the same problem as described by @jodastephen. Our HCL Notes Client delivers a JavaMail 1.6 library, which conflicts with our Eclipse Plugin which tries to use Jakarta/Angus Mail. Because JavaMail contains an own, incompatible META-INF/mailcap we do also get the ClassCastExceptions.
Our question is how to workaround that behaviour or if you can tell us when an updated Jakarta Mail which uses a different META-INF/mailcap file will be released.
Best regards.

[jmehrens]

@NicoPrenzel I haven't confirmed this or written up a real test but, I think you could try one of the following:

1. Create a new javax.activation.MailcapCommandMap(InputStream) and load a specific mailcap file with only the com.sun/javax entries. Then call javax.activation.CommandMap.setDefaultCommandMap. Create a new jakarta.activation.MailcapCommandMap(InputStream) and load a specific mailcap file with only the org.eclipse/jakarta entries.
2. Create a custom child classloader and override the resource fetching methods to walk the caller and correctly fetch "the right" mailcap file.

I haven't tested either workaround so they might not actually work.

[NicoPrenzel]

@jmehrens Thanks for your answer.
In the meantime i've found a solution to create an own DataContentHandlerFactory and map the mime types manually to the correct classes. Of course i do appreciate a more general solution.