java.lang.ClassFormatError: Absent Code attribute in method that is not native or abstract in class file javax/mail/MessagingException

Question

I have a maven dependency for javaee Bibliothek.

<dependency>
    <groupId>javax</groupId>
    <artifactId>javaee-api</artifactId>
    <version>6.0</version>
    <scope>provided</scope>
</dependency>

I get the error in Eclipse in some classes.

java.lang.ClassFormatError: Absent Code attribute in method that is not native or abstract in class file javax/mail/MessagingException

I added javax.mail dependency.

<dependency>
    <groupId>javax.mail</groupId>
    <artifactId>mail</artifactId>
    <version>1.4.5</version>
</dependency>

It did not not work. Any Idea??

Subacid

Answer 1

It did not work because classes from javax/javaee-api/provided dependency are specially constructed. They are not usable runtime because implementation of methods is missing.

Simply adding classes from javax.mail/mail/1.4.5 dependency to the classpath does not help, because classes from javax/javaee-api/provided are already there. Having javax.mail/mail/1.4.5 dependecy alone solves your problem, but most likely you also need other classes from javax/javaee-api/provided.

What you can do is to get rid of javax/javaee-api/provided dependency and get these classes for example from the dependencies provided by target application server. You can use for example following:

   <dependency>
        <groupId>org.jboss.spec</groupId>
        <artifactId>jboss-javaee-6.0</artifactId>
        <version>1.0.0.Final</version>
        <type>pom</type>
        <scope>provided</scope>
     </dependency>

Because scope is provided, it does not affect the artifact to be built. That's why you can use this one also with other application servers than JBoss. It is same API as in your original dependency, but it contains normal classes.

Dissimilation

I added more instructions to answer. – Dissimilation

I always put the javaee-api dependency LAST in the pom.xml, with the implementation jars before it, that fixes it too – Earthshine

Answer 2

Weird but the following order works for me,

    <dependency>
        <groupId>javax.mail</groupId>
        <artifactId>mail</artifactId>
        <version>1.4</version>
    </dependency>

    <dependency>
        <groupId>javax</groupId>
        <artifactId>javaee-web-api</artifactId>
        <version>6.0</version>
        <scope>provided</scope>
    </dependency>

The reverse won't work.

Stockholder

This Actually works. @prayag upd Can you please post little more details about how it works exactly. – Gertiegertrud

This works for me. The explaination IMHO is the following: Order is worth in class path. So, this way the compiler uses the javax.mail.MessagingException class contained in the first package, instead of the second one. – Gilboa

Answer 3

in my case, only use the library:

<dependency>
    <groupId>javax.mail</groupId>
    <artifactId>mail</artifactId>
    <version>1.4</version>
</dependency>

Run with JDK 6 and Tomcat without problems

Rumania

I need also the other libraries from javaee – Subacid

Answer 4

If you add them to your pom in this order: javax.mail javaee-web-api it is pretty logical that it will work, because the runtime finds the necessary class first (with the proper implementation) from javax.mail, ignoring any similar class (without implementation) from javaee-web-api.

Anastice

Answer 5

In my case i use following order. Work very well with JDK6.

<dependency>
    <groupId>javax.mail</groupId>
    <artifactId>mail</artifactId>
    <version>1.4</version>
    <scope>provided</scope>
    <exclusions>
        <exclusion>
            <groupId>javax.activation</groupId>
            <artifactId>activation</artifactId>
        </exclusion>
    </exclusions>
</dependency>

<dependency>
    <groupId>javaee</groupId>
    <artifactId>javaee-api</artifactId>
    <version>5</version>
    <scope>provided</scope>
</dependency>

Oleo