Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using Jakarta mail and Javamail in the same runtime #527

Open
rickstev opened this issue Feb 17, 2021 · 4 comments
Open

Using Jakarta mail and Javamail in the same runtime #527

rickstev opened this issue Feb 17, 2021 · 4 comments

Comments

@rickstev
Copy link

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
Copy link
Contributor

lukasj commented Feb 17, 2021

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
Copy link
Author

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
Copy link
Contributor

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

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/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants