Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-70627

Class conflict between javax.mail and jakarta

      Attempting to use recent versions of the email extension plugin (among others) results in a verification error in the JDK for com.sun.mail.smtp.SMTPAddressSucceededException.

      It appears to be because the jakarta mail-api plugin rebundles a variation of com.sun.mail.smtp.SMTPAddressSucceededException that extends jakarta.mail.MessagingException whereas the one from java-mail 1.6.2 extends javax.mail.MessagingException.

      The jakarta-mail-api ends up conflicting with some of the java-mail classes because javax-mail-api plugin is a detached plugin included in Jenkins core and I suspect it thus has classloading precedence over the jakarta-mail-api plugin.

      The latest Jenkins core includes jakarta-mail-api as a detached plugin and although I have not tested this I suspect that it will ultimately fix the issue as alphabetical class loading will prefer the jakarta classes over the java mail ones. It appears it was added in Jenkins 2.378 by this PR as a mitigation of JENKINS-69361

      Workaround is to use older versions of plugins that do not make use of the jakarta-mail-api plugin.

      22:07:46  java.lang.VerifyError: Inconsistent stackmap frames at branch target 819
      22:07:46  Exception Details:
      22:07:46    Location:
      22:07:46      com/sun/mail/smtp/SMTPTransport.rcptTo()V @819: iinc
      22:07:46    Reason:
      22:07:46      Type 'com/sun/mail/smtp/SMTPAddressSucceededException' (current frame, locals[5]) is not assignable to 'javax/mail/MessagingException' (stack map, locals[5])
      . . .
      22:07:46  	at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
      22:07:46  	at java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3137)
      22:07:46  	at java.base/java.lang.Class.getConstructor0(Class.java:3342)
      22:07:46  	at java.base/java.lang.Class.getConstructor(Class.java:2151)
      22:07:46  	at jakarta.mail.Session.getService(Session.java:849)
      22:07:46  	at jakarta.mail.Session.getTransport(Session.java:772)
      22:07:46  	at jakarta.mail.Session.getTransport(Session.java:713)
      22:07:46  	at jakarta.mail.Session.getTransport(Session.java:693)
      22:07:46  	at jakarta.mail.Session.getTransport(Session.java:750)
      22:07:46  	at hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:520)
      22:07:46  	at hudson.plugins.emailext.EmailExtStep$EmailExtStepExecution.run(EmailExtStep.java:249)
      22:07:46  	at hudson.plugins.emailext.EmailExtStep$EmailExtStepExecution.run(EmailExtStep.java:182)
      22:07:46  	at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47)
      22:07:46  	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
      22:07:46  	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
      22:07:46  	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
      22:07:46  	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
      22:07:46  	at java.base/java.lang.Thread.run(Thread.java:829)
      

          [JENKINS-70627] Class conflict between javax.mail and jakarta

          I would assume that the solution is to uninstall the javax-mail-api plugin ?
          Also the latest release 2.1.0 of Jakarta Mail moved those classes to angus-mail. So that might fix this problem too.

          Allan BURDAJEWICZ added a comment - I would assume that the solution is to uninstall the javax-mail-api plugin ? Also the latest release 2.1.0 of Jakarta Mail moved those classes to angus-mail . So that might fix this problem too.

          Basil Crow added a comment -

          I would assume that the solution is to uninstall the javax-mail-api plugin ?

          That should certainly chase away the problem, but there are 1,507 plugins with an implied dependency on javax-mail-api, so that could be a challenge.

          Also the latest release 2.1.0 of Jakarta Mail moved those classes to angus-mail. So that might fix this problem too.

          The latest release of Jakarta Mail is a no-go on Jenkins due to jakartaee/mail-api#665.


          If javax-mail-api truly were incompatible with jakarta-mail-api we would have heard far more complaints from the 150,000+ users who have both plugins installed. Indeed, https://github.com/jenkinsci/jakarta-mail-api-plugin/blob/32b196156bd5774402bd1d5ec6de8ff3665e4b9c/pom.xml#L75-L86 and https://github.com/jenkinsci/javax-mail-api-plugin/blob/57b30f8d54d304b7b97aee8134f7821eb2ea6d24/pom.xml#L75-L86 are meant to work around this exact problem, and the workaround is (by and large) successful: I just successfully sent mail to Gmail (using the latest Mailer and jakarta-mail-api) on my test Jenkins installation with both javax-mail-api and jakarta-mail-api installed. So the problem is that this particular user is doing something unusual for which the existing workaround is not taking effect. To be able to help, we would need to know more information like the version of Jenkins and complete list of plugins installed, which JDK is being used, and steps to reproduce the problem from scratch in that environment on a clean Jenkins installation.

          Basil Crow added a comment - I would assume that the solution is to uninstall the javax-mail-api plugin ? That should certainly chase away the problem, but there are 1,507 plugins with an implied dependency on javax-mail-api , so that could be a challenge. Also the latest release 2.1.0 of Jakarta Mail moved those classes to angus-mail . So that might fix this problem too. The latest release of Jakarta Mail is a no-go on Jenkins due to jakartaee/mail-api#665 . If javax-mail-api truly were incompatible with jakarta-mail-api we would have heard far more complaints from the 150,000+ users who have both plugins installed. Indeed, https://github.com/jenkinsci/jakarta-mail-api-plugin/blob/32b196156bd5774402bd1d5ec6de8ff3665e4b9c/pom.xml#L75-L86 and https://github.com/jenkinsci/javax-mail-api-plugin/blob/57b30f8d54d304b7b97aee8134f7821eb2ea6d24/pom.xml#L75-L86 are meant to work around this exact problem, and the workaround is (by and large) successful: I just successfully sent mail to Gmail (using the latest Mailer and jakarta-mail-api ) on my test Jenkins installation with both javax-mail-api and jakarta-mail-api installed. So the problem is that this particular user is doing something unusual for which the existing workaround is not taking effect. To be able to help, we would need to know more information like the version of Jenkins and complete list of plugins installed, which JDK is being used, and steps to reproduce the problem from scratch in that environment on a clean Jenkins installation.

          FWIW, we ran into a somewhat similar problem recently:

          12:47:20 FATAL: jakarta.mail.Provider: com.sun.mail.imap.IMAPProvider not a subtype
          12:47:20 java.util.ServiceConfigurationError: jakarta.mail.Provider: com.sun.mail.imap.IMAPProvider not a subtype
          12:47:20     at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:589)
          12:47:20     at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1237)
          12:47:20     at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1265)
          12:47:20     at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1300)
          12:47:20     at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1385)
          12:47:20     at jakarta.mail.Session.loadProviders(Session.java:964)
          12:47:20     at jakarta.mail.Session.<init>(Session.java:254)
          12:47:20     at jakarta.mail.Session.getInstance(Session.java:281)
          12:47:20     at hudson.plugins.emailext.ExtendedEmailPublisherDescriptor.createSession(ExtendedEmailPublisherDescriptor.java:377)
          12:47:20     at hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:489)
          12:47:20     at hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:444)
          12:47:20     at hudson.plugins.emailext.ExtendedEmailPublisher.prebuild(ExtendedEmailPublisher.java:344)
           

          I assume this happened because the service loader picked up IMAPProvider which extends javax.mail.Provider (from the Javax Mail API plugin) instead of the one which extends jakarta.mail.Provider (from the Jakarta Mail API plugin).

           

          The weirdest thing about this one was that it only happened when the job in question was tied to one specific agent. I couldn't reproduce this with different agents. I tought that sending the emails happens on the controller and should not be dependent on the agent in any way, but maybe I'm wrong. The problem went away after deleting the agent from Jenkins and recreating it.

          Radoslaw Moszczynski added a comment - FWIW, we ran into a somewhat similar problem recently: 12:47:20 FATAL: jakarta.mail.Provider: com.sun.mail.imap.IMAPProvider not a subtype 12:47:20 java.util.ServiceConfigurationError: jakarta.mail.Provider: com.sun.mail.imap.IMAPProvider not a subtype 12:47:20     at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:589) 12:47:20     at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1237) 12:47:20     at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1265) 12:47:20     at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1300) 12:47:20     at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1385) 12:47:20     at jakarta.mail.Session.loadProviders(Session.java:964) 12:47:20     at jakarta.mail.Session.<init>(Session.java:254) 12:47:20     at jakarta.mail.Session.getInstance(Session.java:281) 12:47:20     at hudson.plugins.emailext.ExtendedEmailPublisherDescriptor.createSession(ExtendedEmailPublisherDescriptor.java:377) 12:47:20     at hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:489) 12:47:20     at hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:444) 12:47:20     at hudson.plugins.emailext.ExtendedEmailPublisher.prebuild(ExtendedEmailPublisher.java:344) I assume this happened because the service loader picked up IMAPProvider which extends javax.mail.Provider (from the Javax Mail API plugin) instead of the one which extends jakarta.mail.Provider (from the Jakarta Mail API plugin).   The weirdest thing about this one was that it only happened when the job in question was tied to one specific agent. I couldn't reproduce this with different agents. I tought that sending the emails happens on the controller and should not be dependent on the agent in any way, but maybe I'm wrong. The problem went away after deleting the agent from Jenkins and recreating it.

          Stefan added a comment -

          I had this problem for one customer which has several Jenkins installations.

          • Agents
            • each system has 5-15 agents
            • most agents are running Windows10 (with Eclipse Adoptium JRE 11.0.19)
            • some agents are running RHEL8 or RHEL9 with OpenJDK 11.0.19 or 11.0.21
            • all jenkins masters are running Jenkins 2.387.2 (update is pending) on RHEL8 with OpenJDK 11.0.19
          • Jobs, problem occurrence
            • Roughly ~150 out of our ~2000 jobs are running on the (linux) masters
            • Problem occurred only on 11 out of those 150 jobs, not on any other job.
            • Problem occurred only in a relatively small percentage of the builds, between 3% and 10% of the builds per job.
            • Problem has fully disappeared five weeks ago, right after explicitly removing the javax-mail-api plugin (in favor of the jakarta-mail-api plugin). Before that removal, Problem was visible for at least three months.
          • Plugin version of jakarta-mail-api is 2.0.1-3 (current latest), plugin version of (removed) javax-mail-api was 1.6.2-9.

           

          Although my stacktrace was different (see below), I still do believe this to be the same problem of incompatibility between javax-mail-api and jakarta-mail-api

          FATAL: jakarta.mail.Provider: com.sun.mail.imap.IMAPProvider not a subtype
          java.util.ServiceConfigurationError: jakarta.mail.Provider: com.sun.mail.imap.IMAPProvider not a subtype
                  at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:589)
                  at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1237)
                  at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1265)
                  at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1300)
                  at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1385)
                  at jakarta.mail.Session.loadProviders(Session.java:964)
                  at jakarta.mail.Session.<init>(Session.java:254)
                  at jakarta.mail.Session.getInstance(Session.java:281)
                  at hudson.tasks.Mailer$DescriptorImpl.createSession(Mailer.java:418)
                  at hudson.tasks.Mailer$DescriptorImpl.createSession(Mailer.java:356)
                  at jenkins.plugins.mailer.tasks.MimeMessageBuilder.buildMimeMessage(MimeMessageBuilder.java:199)
                  at hudson.tasks.MailSender.createEmptyMail(MailSender.java:407)
                  at hudson.tasks.MailSender.createFailureMail(MailSender.java:274)
                  at hudson.tasks.MailSender.createMail(MailSender.java:182)
                  at hudson.tasks.MailSender.run(MailSender.java:112)
                  at hudson.tasks.Mailer.perform(Mailer.java:175)
                  at hudson.tasks.Mailer.perform(Mailer.java:138)
                  at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
                  at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:818)
                  at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:767)
                  at hudson.model.Build$BuildExecution.post2(Build.java:179)
                  at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:711)
                  at hudson.model.Run.execute(Run.java:1925)
                  at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:44)
                  at hudson.model.ResourceController.execute(ResourceController.java:101)
                  at hudson.model.Executor.run(Executor.java:442) 

          Stefan added a comment - I had this problem for one customer which has several Jenkins installations. Agents each system has 5-15 agents most agents are running Windows10 (with Eclipse Adoptium JRE 11.0.19) some agents are running RHEL8 or RHEL9 with OpenJDK 11.0.19 or 11.0.21 all jenkins masters are running Jenkins 2.387.2 (update is pending) on RHEL8 with OpenJDK 11.0.19 Jobs, problem occurrence Roughly ~150 out of our ~2000 jobs are running on the (linux) masters Problem occurred only on 11 out of those 150 jobs, not on any other job. Problem occurred only in a relatively small percentage of the builds, between 3% and 10% of the builds per job. Problem has fully disappeared five weeks ago, right after explicitly removing the javax-mail-api plugin (in favor of the jakarta-mail-api plugin). Before that removal, Problem was visible for at least three months. Plugin version of jakarta-mail-api is 2.0.1-3 (current latest), plugin version of (removed) javax-mail-api was 1.6.2-9.   Although my stacktrace was different (see below), I still do believe this to be the same problem of incompatibility between javax-mail-api and jakarta-mail-api FATAL: jakarta.mail.Provider: com.sun.mail.imap.IMAPProvider not a subtype java.util.ServiceConfigurationError: jakarta.mail.Provider: com.sun.mail.imap.IMAPProvider not a subtype         at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:589)         at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1237)         at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1265)         at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1300)         at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1385)         at jakarta.mail.Session.loadProviders(Session.java:964)         at jakarta.mail.Session.<init>(Session.java:254)         at jakarta.mail.Session.getInstance(Session.java:281)         at hudson.tasks.Mailer$DescriptorImpl.createSession(Mailer.java:418)         at hudson.tasks.Mailer$DescriptorImpl.createSession(Mailer.java:356)         at jenkins.plugins.mailer.tasks.MimeMessageBuilder.buildMimeMessage(MimeMessageBuilder.java:199)         at hudson.tasks.MailSender.createEmptyMail(MailSender.java:407)         at hudson.tasks.MailSender.createFailureMail(MailSender.java:274)         at hudson.tasks.MailSender.createMail(MailSender.java:182)         at hudson.tasks.MailSender.run(MailSender.java:112)         at hudson.tasks.Mailer.perform(Mailer.java:175)         at hudson.tasks.Mailer.perform(Mailer.java:138)         at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)         at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:818)         at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:767)         at hudson.model.Build$BuildExecution.post2(Build.java:179)         at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:711)         at hudson.model.Run.execute(Run.java:1925)         at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:44)         at hudson.model.ResourceController.execute(ResourceController.java:101)         at hudson.model.Executor.run(Executor.java:442)

          Basil Crow added a comment -

          I think this would be resolved by upgrading the Jenkins Jakarta Mail library plugin to recent versions of the upstream Mail API / Angus Mail, which avoid the com.sun.mail package namespace and therefore the potential for class loading conflicts. Unfortunately, we cannot upgrade until https://github.com/jakartaee/mail-api/pull/701 is merged and released.

          Basil Crow added a comment - I think this would be resolved by upgrading the Jenkins Jakarta Mail library plugin to recent versions of the upstream Mail API / Angus Mail, which avoid the com.sun.mail package namespace and therefore the potential for class loading conflicts. Unfortunately, we cannot upgrade until https://github.com/jakartaee/mail-api/pull/701 is merged and released.

          Basil Crow added a comment -

          This should be resolved in the following two releases, which must be applied in lockstep:

          Basil Crow added a comment - This should be resolved in the following two releases, which must be applied in lockstep: Jakarta Activation API 2.1.3-1 Jakarta Mail API 2.1.3-1

            basil Basil Crow
            mrichar2 Mark R
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: