PowerMock throws NoSuchMethodError (setMockName) - java

I'm trying to mock a constructor using PowerMockito but every time I run the test I get the following error:
java.lang.NoSuchMethodError: org.mockito.internal.creation.MockSettingsImpl.setMockName(Lorg/mockito/mock/MockName;)Lorg/mockito/internal/creation/settings/CreationSettings;
at org.powermock.api.mockito.internal.mockcreation.MockCreator.createMethodInvocationControl(MockCreator.java:107)
at org.powermock.api.mockito.internal.mockcreation.MockCreator.mock(MockCreator.java:60)
at org.powermock.api.mockito.internal.expectation.DefaultConstructorExpectationSetup.createNewSubstituteMock(DefaultConstructorExpectationSetup.java:105)
at org.powermock.api.mockito.internal.expectation.DefaultConstructorExpectationSetup.withAnyArguments(DefaultConstructorExpectationSetup.java:71)
I have the following PowerMock dependencies in my project:
org.powermock:powermock-module-junit4:1.5.6
org.powermock:powermock-mockito-release-full:1.5.6
I've traced the dependency tree of my project and fixed conflicts so that mockito-all:1.9.5 gets included in the build.


Make sure powermockito and mockito versions are aligned as in this versions chart - MockitoUsage#supported-versions,
Mockito | PowerMock
------------------------------------------------------------------------------
2.0.0-beta - 2.0.42-beta | 1.6.5+
------------------------------------------------------------------------------
1.10.19 | 1.6.4
1.10.8 - 1.10.x | 1.6.2+
1.9.5-rc1 - 1.9.5 | 1.5.0 - 1.5.6
1.9.0-rc1 & 1.9.0 | 1.4.10 - 1.4.12
1.8.5 | 1.3.9 - 1.4.9
1.8.4 | 1.3.7 & 1.3.8
1.8.3 | 1.3.6
1.8.1 & 1.8.2 | 1.3.5
1.8 | 1.3
1.7 | 1.2.5
Easy way to find mockito and powermock-mockito version using maven is,
mvn dependency:tree | grep mockito
[INFO] | \- org.mockito:mockito-core:jar:1.8.5:compile
[INFO] +- org.mockito:mockito-all:jar:1.8.5:compile
[INFO] +- org.powermock:powermock-api-mockito:jar:1.4.9:compile
Problem could be the conflicting versions of mockito in the application and the one that powermockito uses, conflicting as below in my case where I'm using powermock 1.6.5 which does not support mockito 1.8.5
mvn clean dependency:tree | grep mockito
[INFO] +- org.mockito:mockito-all:jar:1.8.5:compile
[INFO] \- org.powermock:powermock-api-mockito:jar:1.6.5:compile
[INFO] +- org.mockito:mockito-core:jar:1.10.19:compile
[INFO] \- org.powermock:powermock-api-mockito-common:jar:1.6.5:compile


I had
org.mockito
mockito-all
1.8.4
added to my pom.xml apart from powermock's dependecies, removing this worked for me.


My problem was due to conflicting versions of javassist in my project's (transitive) dependencies. What I did was search for all dependencies that put old version of javassist in the build, then exclude them. For example:
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-entitymanager</artifactId>
<version>3.5.1-Final</version>
<scope>provided</scope>
<exclusions>
<exclusion>
<groupId>javassist</groupId>
<artifactId>javassist</artifactId>
</exclusion>
</exclusions>
</dependency>


while migrating springboot from 1.5 to 2.0.7
The versions of mockito in springboot and powermock are different so explicitly give mockito dependency
This is compatible while migrating to springboot 2.0.7
testCompile "org.powermock:powermock-api-mockito2:${powermockVersion}"
testCompile group: 'org.mockito', name: 'mockito-core', version: '2.8.9'
testCompile "org.powermock:powermock-module-junit4:1.7.3"
testCompile "org.powermock:powermock-core:1.7.3"


For me, in Eclipse, the fix to this problem was found in Java Build Path. Click on Order and Export tab. Move Web App Libraries to bottom. Note, that when appropriate, this will also allow you to view source of 3rd party libraries when Eclipse tells you that source cannot be found.


In my case it was a conflict dependency.
I had fix it after exclude mockito-core artifact:
<dependency>
<groupId>com.googlecode.catch-exception</groupId>
<artifactId>catch-exception</artifactId>
<exclusions>
<exclusion>
<groupId>org.mockito</groupId>
<artifactId>mockito-core</artifactId>
</exclusion>
</exclusions>
<version>1.0.4</version>
<scope>test</scope>
</dependency>


Also, consider removing PowerMock, bytebuddy and objenesis dependencies at all. Keep only the following Mockito dependency.
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-core</artifactId>
<version>2.7.12</version>
<scope>test</scope>
</dependency>
This should fix the error for the most part of the scenarios.

Related

While compiling Tests Groovy:java.lang.NoClassDefFoundError: Unable to load class org.apache.groovy.jaxb.extensions.JaxbExtensions [duplicate]

I have some code that uses JAXB API classes which have been provided as a part of the JDK in Java 6/7/8. When I run the same code with Java 9, at runtime I get errors indicating that JAXB classes can not be found.
The JAXB classes have been provided as a part of the JDK since Java 6, so why can Java 9 no longer find these classes?

The JAXB APIs are considered to be Java EE APIs and therefore are no longer contained on the default classpath in Java SE 9. In Java 11, they are completely removed from the JDK.
Java 9 introduces the concepts of modules, and by default, the java.se aggregate module is available on the classpath (or rather, module-path). As the name implies, the java.se aggregate module does not include the Java EE APIs that have been traditionally bundled with Java 6/7/8.
Fortunately, these Java EE APIs that were provided in JDK 6/7/8 are still in the JDK, but they just aren't on the classpath by default. The extra Java EE APIs are provided in the following modules:
java.activation
java.corba
java.transaction
java.xml.bind << This one contains the JAXB APIs
java.xml.ws
java.xml.ws.annotation
Quick and dirty solution: (JDK 9/10 only)
To make the JAXB APIs available at runtime, specify the following command-line option:
--add-modules java.xml.bind
But I still need this to work with Java 8!!!
If you try specifying --add-modules with an older JDK, it will blow up because it's an unrecognized option. I suggest one of two options:
You can set any Java 9+ only options using the JDK_JAVA_OPTIONS environment variable. This environment variable is automatically read by the java launcher for Java 9+.
You can add the -XX:+IgnoreUnrecognizedVMOptions to make the JVM silently ignore unrecognized options, instead of blowing up. But beware! Any other command-line arguments you use will no longer be validated for you by the JVM. This option works with Oracle/OpenJDK as well as IBM JDK (as of JDK 8sr4).
Alternate quick solution: (JDK 9/10 only)
Note that you can make all of the above Java EE modules available at run time by specifying the --add-modules java.se.ee option. The java.se.ee module is an aggregate module that includes java.se.ee as well as the above Java EE API modules. Note, this doesn't work on Java 11 because java.se.ee was removed in Java 11.
Proper long-term solution: (JDK 9 and beyond)
The Java EE API modules listed above are all marked #Deprecated(forRemoval=true) because they are scheduled for removal in Java 11. So the --add-module approach will no longer work in Java 11 out-of-the-box.
What you will need to do in Java 11 and forward is include your own copy of the Java EE APIs on the classpath or module path. For example, you can add the JAX-B APIs as a Maven dependency like this:
<!-- API, java.xml.bind module -->
<dependency>
<groupId>jakarta.xml.bind</groupId>
<artifactId>jakarta.xml.bind-api</artifactId>
<version>2.3.2</version>
</dependency>
<!-- Runtime, com.sun.xml.bind module -->
<dependency>
<groupId>org.glassfish.jaxb</groupId>
<artifactId>jaxb-runtime</artifactId>
<version>2.3.2</version>
</dependency>
See the JAXB Reference Implementation page for more details on JAXB.
For full details on Java modularity, see JEP 261: Module System
As of July 2022, the latest version of the bind-api and jaxb-runtime is 4.0.0. So you can also use
<version>4.0.0</version>
...within those dependency clauses. But if you do so, the package names have changed from javax.xml.bind... to jakarta.xml.bind.... You will need to modify your source code to use these later versions of the JARs.
For Gradle or Android Studio developer: (JDK 9 and beyond)
Add the following dependencies to your build.gradle file:
dependencies {
// JAX-B dependencies for JDK 9+
implementation "jakarta.xml.bind:jakarta.xml.bind-api:2.3.2"
implementation "org.glassfish.jaxb:jaxb-runtime:2.3.2"
}

In my case (spring boot fat jar) I just add the following to pom.xml.
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.3.1</version>
</dependency>

Clean solution for all JDKs >= 9
You need to add two dependencies to your build
the jaxb-api
a jaxb implementation
As an implementation I chose to use the reference implementation by glassfish to get rid of old com.sun classes / libraries.
So as a result I added in my maven build
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.3.1</version>
</dependency>
<dependency>
<groupId>org.glassfish.jaxb</groupId>
<artifactId>jaxb-runtime</artifactId>
<version>2.3.1</version>
</dependency>
Note that from version 2.3.1 you don't need to add the javax.activation any longer. (see https://github.com/eclipse-ee4j/jaxb-ri/issues/1222)

None of these solutions worked fine for me in the recent JDK 9.0.1.
I found that this list of dependencies is enough for a proper functioning, so you don't need to explicitly specify --add-module (though it is specified within these dependencies's pom's). The only you need is to specify this list of dependencies:
<dependencies>
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.3.0</version>
</dependency>
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-impl</artifactId>
<version>2.3.0</version>
</dependency>
<dependency>
<groupId>org.glassfish.jaxb</groupId>
<artifactId>jaxb-runtime</artifactId>
<version>2.3.0</version>
</dependency>
<dependency>
<groupId>javax.activation</groupId>
<artifactId>activation</artifactId>
<version>1.1.1</version>
</dependency>
</dependencies>

This worked for me:
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.3.0</version>
</dependency>
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>eclipselink</artifactId>
<version>2.7.0</version>
</dependency>
Update
As #Jasper suggested, in order to avoid depending on the entire EclipseLink library, you can also just depend on EclipseLink MOXy:
Maven
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>org.eclipse.persistence.moxy</artifactId>
<version>2.7.3</version>
</dependency>
Gradle
compile group: 'org.eclipse.persistence', name: 'org.eclipse.persistence.moxy', version: '2.7.3'
As dependencies for my Java 8 app, which produces a *.jar which can be run by both JRE 8 or JRE 9 with no additional arguments.
In addition, this needs to be executed somewhere before JAXB API will be used:
System.setProperty("javax.xml.bind.JAXBContextFactory", "org.eclipse.persistence.jaxb.JAXBContextFactory");
Works great so far, as a workaround. Doesn't look like a perfect solution though...

it´s because java version if you are using jdk 9 or a later version just add this to your pom
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.3.0</version>
</dependency>

To solve this, I have imported some JAR files in my project:
javax.activation-1.2.0.jar
http://search.maven.org/remotecontent?filepath=com/sun/activation/javax.activation/1.2.0/javax.activation-1.2.0.jar
jaxb-api-2.3.0.jar
http://search.maven.org/remotecontent?filepath=javax/xml/bind/jaxb-api/2.3.0/jaxb-api-2.3.0.jar
jaxb-core-2.3.0.jar
http://search.maven.org/remotecontent?filepath=com/sun/xml/bind/jaxb-core/2.3.0/jaxb-core-2.3.0.jar
jaxb-impl-2.3.0.jar
http://search.maven.org/remotecontent?filepath=com/sun/xml/bind/jaxb-impl/2.3.0/jaxb-impl-2.3.0.jar
Download above files and copy them into libs folder in the project
Add the imported JAR files in Java Build Path

At the time of compilation as well as run time, add the switch --add-modules java.xml.bind
javac --add-modules java.xml.bind <java file name>
java --add-modules java.xml.bind <class file>
A good introduction of the JDK 9 modules can also be found at :
https://www.youtube.com/watch?v=KZfbRuvv5qc

I encountered this issue when working on a Java Project in Debian 10.
Each time I start the appliction it throws the error in the log file:
java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
Here's how I solved it:
The issue is often caused when JAXB library (Java Architecture for XML Binding) is missing in the classpath. JAXB is included in Java SE 10 or older, but it is removed from Java SE from Java 11 or newer –moved to Java EE under Jakarta EE project.
So, I checked my Java version using:
java --version
And it gave me this output
openjdk 11.0.8 2020-07-14
OpenJDK Runtime Environment (build 11.0.8+10-post-Debian-1deb10u1)
OpenJDK 64-Bit Server VM (build 11.0.8+10-post-Debian-1deb10u1, mixed mode, sharing)
So I was encountering the JAXBException error because I was using Java 11, which does not have the JAXB library (Java Architecture for XML Binding) is missing in the classpath. JAXB is included in it.
To fix the issue I had to add the JAXB API library to the lib (/opt/tomcat/lib) directory of my tomcat installation:
sudo wget https://repo1.maven.org/maven2/javax/xml/bind/jaxb-api/2.4.0-b180830.0359/jaxb-api-2.4.0-b180830.0359.jar
Then I renamed it from jaxb-api-2.4.0-b180830.0359.jar to jaxb-api.jar:
sudo mv jaxb-api-2.4.0-b180830.0359.jar jaxb-api.jar
Note: Ensure that you change the permission allow tomcat access the file and also change the ownership to tomcat:
sudo chown -R tomcat:tomcat /opt/tomcat
sudo chmod -R 777 /opt/tomcat/
And then I restarted the tomcat server:
sudo systemctl restart tomcat
Resources: [Solved] java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
That's all.

Update April 2019
Changelong for JAXB releases is at https://javaee.github.io/jaxb-v2/doc/user-guide/ch02.html
excerpts:
4.1. Changes between 2.3.0.1 and 2.4.0
JAXB RI is now JPMS modularized:
All modules have native module descriptor.
Removed jaxb-core module, which caused split package issue on JPMS.
RI binary bundle now has single jar per dependency instead of shaded fat jars.
Removed runtime class weaving optimization.
4.2. Changes between 2.3.0 and 2.3.0.1
Removed legacy technology dependencies:
com.sun.xml.bind:jaxb1-impl
net.java.dev.msv:msv-core
net.java.dev.msv:xsdlib
com.sun.xml.bind.jaxb:isorelax
4.3. Changes between 2.2.11 and 2.3.0
Adopt Java SE 9:
JAXB api can now be loaded as a module.
JAXB RI is able to run on Java SE 9 from the classpath.
Addes support for java.util.ServiceLoader mechanism.
Security fixes
Authoritative link is at https://github.com/eclipse-ee4j/jaxb-ri#maven-artifacts
Maven coordinates for JAXB artifacts
jakarta.xml.bind:jakarta.xml.bind-api: API classes for JAXB. Required
to compile against JAXB.
org.glassfish.jaxb:jaxb-runtime: Implementation of JAXB, runtime used
for serialization and deserialization java objects to/from xml.
JAXB fat-jar bundles:
com.sun.xml.bind:jaxb-impl: JAXB runtime fat
jar.
In contrast
to org.glassfish.jaxb artifacts, these jars have all dependency
classes included inside. These artifacts does not contain JPMS module
descriptors.
In Maven projects org.glassfish.jaxb artifacts are
supposed to be used instead.
org.glassfish.jaxb:jaxb-runtime:jar:2.3.2 pulls in:
[INFO] +- org.glassfish.jaxb:jaxb-runtime:jar:2.3.2:compile
[INFO] | +- jakarta.xml.bind:jakarta.xml.bind-api:jar:2.3.2:compile
[INFO] | +- org.glassfish.jaxb:txw2:jar:2.3.2:compile
[INFO] | +- com.sun.istack:istack-commons-runtime:jar:3.0.8:compile
[INFO] | +- org.jvnet.staxex:stax-ex:jar:1.8.1:compile
[INFO] | +- com.sun.xml.fastinfoset:FastInfoset:jar:1.2.16:compile
[INFO] | \- jakarta.activation:jakarta.activation-api:jar:1.2.1:compile
Original Answer
Following Which artifacts should I use for JAXB RI in my Maven project? in Maven, you can use a profile like:
<profile>
<id>java-9</id>
<activation>
<jdk>9</jdk>
</activation>
<dependencies>
<dependency>
<groupId>org.glassfish.jaxb</groupId>
<artifactId>jaxb-runtime</artifactId>
<version>2.3.0</version>
</dependency>
<dependency>
<groupId>javax.activation</groupId>
<artifactId>activation</artifactId>
<version>1.1.1</version>
</dependency>
</dependencies>
</profile>
Dependency tree shows:
[INFO] +- org.glassfish.jaxb:jaxb-runtime:jar:2.3.0:compile
[INFO] | +- org.glassfish.jaxb:jaxb-core:jar:2.3.0:compile
[INFO] | | +- javax.xml.bind:jaxb-api:jar:2.3.0:compile
[INFO] | | +- org.glassfish.jaxb:txw2:jar:2.3.0:compile
[INFO] | | \- com.sun.istack:istack-commons-runtime:jar:3.0.5:compile
[INFO] | +- org.jvnet.staxex:stax-ex:jar:1.7.8:compile
[INFO] | \- com.sun.xml.fastinfoset:FastInfoset:jar:1.2.13:compile
[INFO] \- javax.activation:activation:jar:1.1.1:compile
To use this in Eclipse, say Oxygen.3a Release (4.7.3a) or later, Ctrl-Alt-P, or right-click on the project, Maven, then select the profile.

You need to add JAX-B dependencies when using JDK 9+. For Android Studio user, you'll need to add this to your build.gradle's dependencies {} block:
// Add missing dependencies for JDK 9+
if (JavaVersion.current().ordinal() >= JavaVersion.VERSION_1_9.ordinal()) {
// If you're using #AutoValue or any libs that requires javax.annotation (like Dagger)
compileOnly 'com.github.pengrad:jdk9-deps:1.0'
compileOnly 'javax.annotation:javax.annotation-api:1.3.2'
// If you're using Kotlin
kapt "com.sun.xml.bind:jaxb-core:2.3.0.1"
kapt "javax.xml.bind:jaxb-api:2.3.1"
kapt "com.sun.xml.bind:jaxb-impl:2.3.2"
// If you're using Java
annotationProcessor "com.sun.xml.bind:jaxb-core:2.3.0.1"
annotationProcessor "javax.xml.bind:jaxb-api:2.3.1"
testAnnotationProcessor "com.sun.xml.bind:jaxb-core:2.3.0.1"
testAnnotationProcessor "javax.xml.bind:jaxb-api:2.3.1"
}

I also stumpled accross the ClassNotFoundException:javax.xml.bind.DatatypeConverter using Java 11 and
<dependency>
<groupId>io.jsonwebtoken</groupId>
<artifactId>jjwt</artifactId>
<version>0.9.1</version>
</dependency>
I tried all this stuff around adding javax.xml.bind:jaxb-api or spring boot jakarta.xml.bind-api .. I found a hint for fixes in jjwt version 0.10.0 .. but most importantly, the jjwt package is now split !
Thus, check this reference: https://github.com/jwtk/jjwt/issues/510
Simply, if you use
Java11 and
jjwt 0.9.x and
you face the ClassNotFoundException:javax.xml.bind.DatatypeConverter issue,
go for
jjwt version 0.11.x, but use the splitted packages: https://github.com/jwtk/jjwt#install
You maven wont find a higher version for jjwt dependency, since they split the packages.
Cheers.

This worked for me. Adding only jaxb-api wasn't enough.
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>${jaxb-api.version}</version>
</dependency>
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-impl</artifactId>
<version>${jaxb-api.version}</version>
</dependency>
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-core</artifactId>
<version>${jaxb-api.version}</version>
</dependency>

Go to Your Build.gradle and add below dependencies for both Java 9 or Java 10.
sourceCompatibility = 10 // You can also decrease your souce compatibility to 1.8
//java 9+ does not have Jax B Dependents
compile group: 'javax.xml.bind', name: 'jaxb-api', version: '2.3.0'
compile group: 'com.sun.xml.bind', name: 'jaxb-core', version: '2.3.0'
compile group: 'com.sun.xml.bind', name: 'jaxb-impl', version: '2.3.0'
compile group: 'javax.activation', name: 'activation', version: '1.1.1'

You can use --add-modules=java.xml.bind JVM option to add xml bind module to JVM run-time environment.
Eg: java --add-modules=java.xml.bind XmlTestClass

The root cause of this issue is that Gradle Daemon using JDK11, either you set your JAVA_HOME to JDK11 or your running your Gradle Task in the shared daemon which running with JDK11.
For Android:
Check your Project Structure settings, you can change the JDK to JDK8 from there.
You can also set a JAVA_HOME and points to java8 home.

For Java Web Start Execution we can use Andy Guibert's suggestion like this:
<j2se version="1.6+"
java-vm-args="-XX:+IgnoreUnrecognizedVMOptions --add-modules=java.se.ee"/>
Note the extra "=" in the --add-modules. See this OpenJDK Ticket or the last note in "Understanding Runtime Access Warnings" of the Java Platform, Standard Edition Oracle JDK 9 Migration Guide.

add javax.xml.bind dependency in pom.xml
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.3.0</version>
</dependency>

Adding the below dependency worked for me.
<!-- API, java.xml.bind module -->
<dependency>
<groupId>jakarta.xml.bind</groupId>
<artifactId>jakarta.xml.bind-api</artifactId>
<version>2.3.2</version>
</dependency>
<!-- Runtime, com.sun.xml.bind module -->
<dependency>
<groupId>org.glassfish.jaxb</groupId>
<artifactId>jaxb-runtime</artifactId>
<version>2.3.2</version>
</dependency>

This solved my problems with dependencies running Apache Camel 2.24.1 on Java 12:
<dependency>
<groupId>javax.activation</groupId>
<artifactId>activation</artifactId>
<version>1.1.1</version>
</dependency>
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.3.1</version>
</dependency>
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-core</artifactId>
<version>2.3.0.1</version>
</dependency>
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-impl</artifactId>
<version>2.3.0.1</version>
</dependency>

Since JavaEE is now governed by https://jakarta.ee/, the new Maven coordinates as of 2.3.2 are:
https://eclipse-ee4j.github.io/jaxb-ri/#maven-artifacts
The first released jaxb.version is 2.3.2.
<properties>
<jaxb.version>2.3.2</jaxb.version>
</properties>
<dependency>
<groupId>jakarta.xml.bind</groupId>
<artifactId>jakarta.xml.bind-api</artifactId>
<version>${jaxb.version}</version>
</dependency>
<dependency>
<groupId>org.glassfish.jaxb</groupId>
<artifactId>jaxb-runtime</artifactId>
<version>${jaxb.version}</version>
</dependency>

I followed this URL and the below settings had really helped me. I use Java 10 with STS IDE in Macbook Pro. It works like a charm.
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.3.0</version>
</dependency>
<dependency>
<groupId>org.glassfish.jaxb</groupId>
<artifactId>jaxb-runtime</artifactId>
<version>2.3.0</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>javax.activation</groupId>
<artifactId>javax.activation-api</artifactId>
<version>1.2.0</version>
</dependency>

I encountered the same issue using Spring Boot 2.0.5.RELEASE on Java 11.
Adding javax.xml.bind:jaxb-api:2.3.0 alone did not fix the problem. I also had to update Spring Boot to the latest Milestone 2.1.0.M2, so I assume this will be fixed in the next official release.

As the official documentation states:
When upgrading you may face the following:
java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
Hibernate typically requires JAXB that’s no longer provided by default. You can
add the java.xml.bind module to restore this functionality with Java9
or Java10 (even if the module is deprecated).
As of Java11, the module is not available so your only option is to
add the JAXB RI (you can do that as of Java9 in place of adding the
java.xml.bind module:
Maven
<dependency>
<groupId>org.glassfish.jaxb</groupId>
<artifactId>jaxb-runtime</artifactId>
</dependency>
Gradle (build.gradle.kts):
implementation("org.glassfish.jaxb:jaxb-runtime")
Gradle (build.gradle)
implementation 'org.glassfish.jaxb:jaxb-runtime'
If you rather specify a specific version, take a look here:
https://mvnrepository.com/artifact/org.glassfish.jaxb/jaxb-runtime

Not an answer, but an addendum: I got because running groovysh (Groovy 2.4.13) if JAVA_HOME points to a Java 9 installation (java version "9.0.1" to be precise) fails abysmally:
java.lang.reflect.InvocationTargetException
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:107)
at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:129)
Caused by: java.lang.NoClassDefFoundError: Unable to load class groovy.xml.jaxb.JaxbGroovyMethods due to missing dependency javax/xml/bind/JAXBContext
at org.codehaus.groovy.vmplugin.v5.Java5.configureClassNode(Java5.java:400)
at org.codehaus.groovy.ast.ClassNode.lazyClassInit(ClassNode.java:277)
at org.codehaus.groovy.ast.ClassNode.getMethods(ClassNode.java:397)
...
..
.
..
...
at org.codehaus.groovy.tools.shell.Groovysh.<init>(Groovysh.groovy:135)
at org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:232)
at org.codehaus.groovy.tools.shell.Main.<init>(Main.groovy:66)
at org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:232)
at org.codehaus.groovy.tools.shell.Main.main(Main.groovy:163)
... 6 more
The solution was to:
Go to the JAXB Project at github.io ("JAXB is licensed under a dual license - CDDL 1.1 and GPL 2.0 with Class-path Exception")
Download jaxb-ri-2.3.0.zip
Unzip wherever you put your java infrastructure files (in my case, /usr/local/java/jaxb-ri/). Other solution may exist (maybe via SDKMAN, I dunno)
Make sure the jars in the lib subdirectory are on the CLASSPATH. I do it via a script started on bash startup, called /etc/profile.d/java.sh, where I added (among many other lines) the following loop:
Packed into a function...
function extend_qzminynshg {
local BASE="/usr/local/java"
for LIB in jaxb-api.jar jaxb-core.jar jaxb-impl.jar jaxb-jxc.jar jaxb-xjc.jar; do
local FQLIB="$BASE/jaxb-ri/lib/$LIB"
if [[ -f $FQLIB ]]; then
export CLASSPATH=$FQLIB:$CLASSPATH
fi
done
}
extend_qzminynshg; unset extend_qzminynshg
And it works!

you can use this dependency
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.3.0</version>
</dependency>

You only need 1 dependency:
dependencies {
implementation ("jakarta.xml.bind:jakarta.xml.bind-api:2.3.2")

For me in Java 11 and gradle this is what worked out:
plugins {
id 'java'
}
dependencies {
runtimeOnly 'javax.xml.bind:jaxb-api:2.3.1'
}

i want to give a simple and easy solution about this Exception , just downgrade the android studio version upto 4.1.1 or less. Make sure you don't have android studio arctic fox (2020.3.1) version , because latest version don't support old project of android.

OK, I have been having the same kind of issue, but I was using Java 8, and kept getting this error, I tried most of the solutions. but it turns out that my maven was still pointing to java 9 even-though I set the global Java version to 8, as soon as I fixed that it all worked.
For anybody who might have this kind of problem, check out How to fix Maven to use default Java (archived)

Override library version in Spring

I have the spring-ws-security dependency in a Spring Boot 2.1.7 project:
<dependency>
<groupId>org.springframework.ws</groupId>
<artifactId>spring-ws-security</artifactId>
</dependency>
Internally, the spring-ws-security pom has this dependency:
<dependency>
<groupId>org.apache.wss4j</groupId>
<artifactId>wss4j-ws-security-dom</artifactId>
<version>${wss4j.version}</version>
<exclusions>
...
</exclusions>
</dependency>
The parent of spring-ws-security is spring-ws, whose pom has a property:
<wss4j.version>2.2.0</wss4j.version>
I am trying to override this property in my pom file:
<properties>
<wss4j.version>2.2.4</wss4j.version>
...
</properties>
But it keeps taking the original 2.2.0 version:
$ mvn dependency:tree | grep wss4j
[INFO] | +- org.apache.wss4j:wss4j-ws-security-dom:jar:2.2.0:compile
[INFO] | | \- org.apache.wss4j:wss4j-ws-security-common:jar:2.2.0:compile
It takes the 2.2.4 version only if I explicitly supply the dependencies:
<dependency>
<groupId>org.apache.wss4j</groupId>
<artifactId>wss4j-ws-security-dom</artifactId>
<version>2.2.4</version>
</dependency>
<dependency>
<groupId>org.apache.wss4j</groupId>
<artifactId>wss4j</artifactId>
<version>2.2.4</version>
<type>pom</type>
</dependency>
Isn't overriding the property enough? Am I doing something wrong?

Here there are two points to consider:
One if you want to override the version in the properties in pom.xml, then your pom should have a parent-child relationship
second is if you want to use a particular version then we need to
declare the required version in your pom.xml explicitly and may
exclude the dependency from the third party jar and do a mvn clean install
Here is more information on dependency management and properties in maven

As I know, if you leave it blank without define any version. it will get the newest version of its library. So, you are right if you want to override the newest version to old version or certain version, by put the specific version. Have you trying to "mvn clean install" for that project?

Eclipse Unable to create instance of annotation processor org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor [duplicate]

I have some code that uses JAXB API classes which have been provided as a part of the JDK in Java 6/7/8. When I run the same code with Java 9, at runtime I get errors indicating that JAXB classes can not be found.
The JAXB classes have been provided as a part of the JDK since Java 6, so why can Java 9 no longer find these classes?

The JAXB APIs are considered to be Java EE APIs and therefore are no longer contained on the default classpath in Java SE 9. In Java 11, they are completely removed from the JDK.
Java 9 introduces the concepts of modules, and by default, the java.se aggregate module is available on the classpath (or rather, module-path). As the name implies, the java.se aggregate module does not include the Java EE APIs that have been traditionally bundled with Java 6/7/8.
Fortunately, these Java EE APIs that were provided in JDK 6/7/8 are still in the JDK, but they just aren't on the classpath by default. The extra Java EE APIs are provided in the following modules:
java.activation
java.corba
java.transaction
java.xml.bind << This one contains the JAXB APIs
java.xml.ws
java.xml.ws.annotation
Quick and dirty solution: (JDK 9/10 only)
To make the JAXB APIs available at runtime, specify the following command-line option:
--add-modules java.xml.bind
But I still need this to work with Java 8!!!
If you try specifying --add-modules with an older JDK, it will blow up because it's an unrecognized option. I suggest one of two options:
You can set any Java 9+ only options using the JDK_JAVA_OPTIONS environment variable. This environment variable is automatically read by the java launcher for Java 9+.
You can add the -XX:+IgnoreUnrecognizedVMOptions to make the JVM silently ignore unrecognized options, instead of blowing up. But beware! Any other command-line arguments you use will no longer be validated for you by the JVM. This option works with Oracle/OpenJDK as well as IBM JDK (as of JDK 8sr4).
Alternate quick solution: (JDK 9/10 only)
Note that you can make all of the above Java EE modules available at run time by specifying the --add-modules java.se.ee option. The java.se.ee module is an aggregate module that includes java.se.ee as well as the above Java EE API modules. Note, this doesn't work on Java 11 because java.se.ee was removed in Java 11.
Proper long-term solution: (JDK 9 and beyond)
The Java EE API modules listed above are all marked #Deprecated(forRemoval=true) because they are scheduled for removal in Java 11. So the --add-module approach will no longer work in Java 11 out-of-the-box.
What you will need to do in Java 11 and forward is include your own copy of the Java EE APIs on the classpath or module path. For example, you can add the JAX-B APIs as a Maven dependency like this:
<!-- API, java.xml.bind module -->
<dependency>
<groupId>jakarta.xml.bind</groupId>
<artifactId>jakarta.xml.bind-api</artifactId>
<version>2.3.2</version>
</dependency>
<!-- Runtime, com.sun.xml.bind module -->
<dependency>
<groupId>org.glassfish.jaxb</groupId>
<artifactId>jaxb-runtime</artifactId>
<version>2.3.2</version>
</dependency>
See the JAXB Reference Implementation page for more details on JAXB.
For full details on Java modularity, see JEP 261: Module System
As of July 2022, the latest version of the bind-api and jaxb-runtime is 4.0.0. So you can also use
<version>4.0.0</version>
...within those dependency clauses. But if you do so, the package names have changed from javax.xml.bind... to jakarta.xml.bind.... You will need to modify your source code to use these later versions of the JARs.
For Gradle or Android Studio developer: (JDK 9 and beyond)
Add the following dependencies to your build.gradle file:
dependencies {
// JAX-B dependencies for JDK 9+
implementation "jakarta.xml.bind:jakarta.xml.bind-api:2.3.2"
implementation "org.glassfish.jaxb:jaxb-runtime:2.3.2"
}

In my case (spring boot fat jar) I just add the following to pom.xml.
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.3.1</version>
</dependency>

Clean solution for all JDKs >= 9
You need to add two dependencies to your build
the jaxb-api
a jaxb implementation
As an implementation I chose to use the reference implementation by glassfish to get rid of old com.sun classes / libraries.
So as a result I added in my maven build
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.3.1</version>
</dependency>
<dependency>
<groupId>org.glassfish.jaxb</groupId>
<artifactId>jaxb-runtime</artifactId>
<version>2.3.1</version>
</dependency>
Note that from version 2.3.1 you don't need to add the javax.activation any longer. (see https://github.com/eclipse-ee4j/jaxb-ri/issues/1222)

None of these solutions worked fine for me in the recent JDK 9.0.1.
I found that this list of dependencies is enough for a proper functioning, so you don't need to explicitly specify --add-module (though it is specified within these dependencies's pom's). The only you need is to specify this list of dependencies:
<dependencies>
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.3.0</version>
</dependency>
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-impl</artifactId>
<version>2.3.0</version>
</dependency>
<dependency>
<groupId>org.glassfish.jaxb</groupId>
<artifactId>jaxb-runtime</artifactId>
<version>2.3.0</version>
</dependency>
<dependency>
<groupId>javax.activation</groupId>
<artifactId>activation</artifactId>
<version>1.1.1</version>
</dependency>
</dependencies>

This worked for me:
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.3.0</version>
</dependency>
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>eclipselink</artifactId>
<version>2.7.0</version>
</dependency>
Update
As #Jasper suggested, in order to avoid depending on the entire EclipseLink library, you can also just depend on EclipseLink MOXy:
Maven
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>org.eclipse.persistence.moxy</artifactId>
<version>2.7.3</version>
</dependency>
Gradle
compile group: 'org.eclipse.persistence', name: 'org.eclipse.persistence.moxy', version: '2.7.3'
As dependencies for my Java 8 app, which produces a *.jar which can be run by both JRE 8 or JRE 9 with no additional arguments.
In addition, this needs to be executed somewhere before JAXB API will be used:
System.setProperty("javax.xml.bind.JAXBContextFactory", "org.eclipse.persistence.jaxb.JAXBContextFactory");
Works great so far, as a workaround. Doesn't look like a perfect solution though...

it´s because java version if you are using jdk 9 or a later version just add this to your pom
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.3.0</version>
</dependency>

To solve this, I have imported some JAR files in my project:
javax.activation-1.2.0.jar
http://search.maven.org/remotecontent?filepath=com/sun/activation/javax.activation/1.2.0/javax.activation-1.2.0.jar
jaxb-api-2.3.0.jar
http://search.maven.org/remotecontent?filepath=javax/xml/bind/jaxb-api/2.3.0/jaxb-api-2.3.0.jar
jaxb-core-2.3.0.jar
http://search.maven.org/remotecontent?filepath=com/sun/xml/bind/jaxb-core/2.3.0/jaxb-core-2.3.0.jar
jaxb-impl-2.3.0.jar
http://search.maven.org/remotecontent?filepath=com/sun/xml/bind/jaxb-impl/2.3.0/jaxb-impl-2.3.0.jar
Download above files and copy them into libs folder in the project
Add the imported JAR files in Java Build Path

At the time of compilation as well as run time, add the switch --add-modules java.xml.bind
javac --add-modules java.xml.bind <java file name>
java --add-modules java.xml.bind <class file>
A good introduction of the JDK 9 modules can also be found at :
https://www.youtube.com/watch?v=KZfbRuvv5qc

I encountered this issue when working on a Java Project in Debian 10.
Each time I start the appliction it throws the error in the log file:
java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
Here's how I solved it:
The issue is often caused when JAXB library (Java Architecture for XML Binding) is missing in the classpath. JAXB is included in Java SE 10 or older, but it is removed from Java SE from Java 11 or newer –moved to Java EE under Jakarta EE project.
So, I checked my Java version using:
java --version
And it gave me this output
openjdk 11.0.8 2020-07-14
OpenJDK Runtime Environment (build 11.0.8+10-post-Debian-1deb10u1)
OpenJDK 64-Bit Server VM (build 11.0.8+10-post-Debian-1deb10u1, mixed mode, sharing)
So I was encountering the JAXBException error because I was using Java 11, which does not have the JAXB library (Java Architecture for XML Binding) is missing in the classpath. JAXB is included in it.
To fix the issue I had to add the JAXB API library to the lib (/opt/tomcat/lib) directory of my tomcat installation:
sudo wget https://repo1.maven.org/maven2/javax/xml/bind/jaxb-api/2.4.0-b180830.0359/jaxb-api-2.4.0-b180830.0359.jar
Then I renamed it from jaxb-api-2.4.0-b180830.0359.jar to jaxb-api.jar:
sudo mv jaxb-api-2.4.0-b180830.0359.jar jaxb-api.jar
Note: Ensure that you change the permission allow tomcat access the file and also change the ownership to tomcat:
sudo chown -R tomcat:tomcat /opt/tomcat
sudo chmod -R 777 /opt/tomcat/
And then I restarted the tomcat server:
sudo systemctl restart tomcat
Resources: [Solved] java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
That's all.

Update April 2019
Changelong for JAXB releases is at https://javaee.github.io/jaxb-v2/doc/user-guide/ch02.html
excerpts:
4.1. Changes between 2.3.0.1 and 2.4.0
JAXB RI is now JPMS modularized:
All modules have native module descriptor.
Removed jaxb-core module, which caused split package issue on JPMS.
RI binary bundle now has single jar per dependency instead of shaded fat jars.
Removed runtime class weaving optimization.
4.2. Changes between 2.3.0 and 2.3.0.1
Removed legacy technology dependencies:
com.sun.xml.bind:jaxb1-impl
net.java.dev.msv:msv-core
net.java.dev.msv:xsdlib
com.sun.xml.bind.jaxb:isorelax
4.3. Changes between 2.2.11 and 2.3.0
Adopt Java SE 9:
JAXB api can now be loaded as a module.
JAXB RI is able to run on Java SE 9 from the classpath.
Addes support for java.util.ServiceLoader mechanism.
Security fixes
Authoritative link is at https://github.com/eclipse-ee4j/jaxb-ri#maven-artifacts
Maven coordinates for JAXB artifacts
jakarta.xml.bind:jakarta.xml.bind-api: API classes for JAXB. Required
to compile against JAXB.
org.glassfish.jaxb:jaxb-runtime: Implementation of JAXB, runtime used
for serialization and deserialization java objects to/from xml.
JAXB fat-jar bundles:
com.sun.xml.bind:jaxb-impl: JAXB runtime fat
jar.
In contrast
to org.glassfish.jaxb artifacts, these jars have all dependency
classes included inside. These artifacts does not contain JPMS module
descriptors.
In Maven projects org.glassfish.jaxb artifacts are
supposed to be used instead.
org.glassfish.jaxb:jaxb-runtime:jar:2.3.2 pulls in:
[INFO] +- org.glassfish.jaxb:jaxb-runtime:jar:2.3.2:compile
[INFO] | +- jakarta.xml.bind:jakarta.xml.bind-api:jar:2.3.2:compile
[INFO] | +- org.glassfish.jaxb:txw2:jar:2.3.2:compile
[INFO] | +- com.sun.istack:istack-commons-runtime:jar:3.0.8:compile
[INFO] | +- org.jvnet.staxex:stax-ex:jar:1.8.1:compile
[INFO] | +- com.sun.xml.fastinfoset:FastInfoset:jar:1.2.16:compile
[INFO] | \- jakarta.activation:jakarta.activation-api:jar:1.2.1:compile
Original Answer
Following Which artifacts should I use for JAXB RI in my Maven project? in Maven, you can use a profile like:
<profile>
<id>java-9</id>
<activation>
<jdk>9</jdk>
</activation>
<dependencies>
<dependency>
<groupId>org.glassfish.jaxb</groupId>
<artifactId>jaxb-runtime</artifactId>
<version>2.3.0</version>
</dependency>
<dependency>
<groupId>javax.activation</groupId>
<artifactId>activation</artifactId>
<version>1.1.1</version>
</dependency>
</dependencies>
</profile>
Dependency tree shows:
[INFO] +- org.glassfish.jaxb:jaxb-runtime:jar:2.3.0:compile
[INFO] | +- org.glassfish.jaxb:jaxb-core:jar:2.3.0:compile
[INFO] | | +- javax.xml.bind:jaxb-api:jar:2.3.0:compile
[INFO] | | +- org.glassfish.jaxb:txw2:jar:2.3.0:compile
[INFO] | | \- com.sun.istack:istack-commons-runtime:jar:3.0.5:compile
[INFO] | +- org.jvnet.staxex:stax-ex:jar:1.7.8:compile
[INFO] | \- com.sun.xml.fastinfoset:FastInfoset:jar:1.2.13:compile
[INFO] \- javax.activation:activation:jar:1.1.1:compile
To use this in Eclipse, say Oxygen.3a Release (4.7.3a) or later, Ctrl-Alt-P, or right-click on the project, Maven, then select the profile.

You need to add JAX-B dependencies when using JDK 9+. For Android Studio user, you'll need to add this to your build.gradle's dependencies {} block:
// Add missing dependencies for JDK 9+
if (JavaVersion.current().ordinal() >= JavaVersion.VERSION_1_9.ordinal()) {
// If you're using #AutoValue or any libs that requires javax.annotation (like Dagger)
compileOnly 'com.github.pengrad:jdk9-deps:1.0'
compileOnly 'javax.annotation:javax.annotation-api:1.3.2'
// If you're using Kotlin
kapt "com.sun.xml.bind:jaxb-core:2.3.0.1"
kapt "javax.xml.bind:jaxb-api:2.3.1"
kapt "com.sun.xml.bind:jaxb-impl:2.3.2"
// If you're using Java
annotationProcessor "com.sun.xml.bind:jaxb-core:2.3.0.1"
annotationProcessor "javax.xml.bind:jaxb-api:2.3.1"
testAnnotationProcessor "com.sun.xml.bind:jaxb-core:2.3.0.1"
testAnnotationProcessor "javax.xml.bind:jaxb-api:2.3.1"
}

I also stumpled accross the ClassNotFoundException:javax.xml.bind.DatatypeConverter using Java 11 and
<dependency>
<groupId>io.jsonwebtoken</groupId>
<artifactId>jjwt</artifactId>
<version>0.9.1</version>
</dependency>
I tried all this stuff around adding javax.xml.bind:jaxb-api or spring boot jakarta.xml.bind-api .. I found a hint for fixes in jjwt version 0.10.0 .. but most importantly, the jjwt package is now split !
Thus, check this reference: https://github.com/jwtk/jjwt/issues/510
Simply, if you use
Java11 and
jjwt 0.9.x and
you face the ClassNotFoundException:javax.xml.bind.DatatypeConverter issue,
go for
jjwt version 0.11.x, but use the splitted packages: https://github.com/jwtk/jjwt#install
You maven wont find a higher version for jjwt dependency, since they split the packages.
Cheers.

This worked for me. Adding only jaxb-api wasn't enough.
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>${jaxb-api.version}</version>
</dependency>
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-impl</artifactId>
<version>${jaxb-api.version}</version>
</dependency>
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-core</artifactId>
<version>${jaxb-api.version}</version>
</dependency>

Go to Your Build.gradle and add below dependencies for both Java 9 or Java 10.
sourceCompatibility = 10 // You can also decrease your souce compatibility to 1.8
//java 9+ does not have Jax B Dependents
compile group: 'javax.xml.bind', name: 'jaxb-api', version: '2.3.0'
compile group: 'com.sun.xml.bind', name: 'jaxb-core', version: '2.3.0'
compile group: 'com.sun.xml.bind', name: 'jaxb-impl', version: '2.3.0'
compile group: 'javax.activation', name: 'activation', version: '1.1.1'

You can use --add-modules=java.xml.bind JVM option to add xml bind module to JVM run-time environment.
Eg: java --add-modules=java.xml.bind XmlTestClass

The root cause of this issue is that Gradle Daemon using JDK11, either you set your JAVA_HOME to JDK11 or your running your Gradle Task in the shared daemon which running with JDK11.
For Android:
Check your Project Structure settings, you can change the JDK to JDK8 from there.
You can also set a JAVA_HOME and points to java8 home.

For Java Web Start Execution we can use Andy Guibert's suggestion like this:
<j2se version="1.6+"
java-vm-args="-XX:+IgnoreUnrecognizedVMOptions --add-modules=java.se.ee"/>
Note the extra "=" in the --add-modules. See this OpenJDK Ticket or the last note in "Understanding Runtime Access Warnings" of the Java Platform, Standard Edition Oracle JDK 9 Migration Guide.

add javax.xml.bind dependency in pom.xml
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.3.0</version>
</dependency>

Adding the below dependency worked for me.
<!-- API, java.xml.bind module -->
<dependency>
<groupId>jakarta.xml.bind</groupId>
<artifactId>jakarta.xml.bind-api</artifactId>
<version>2.3.2</version>
</dependency>
<!-- Runtime, com.sun.xml.bind module -->
<dependency>
<groupId>org.glassfish.jaxb</groupId>
<artifactId>jaxb-runtime</artifactId>
<version>2.3.2</version>
</dependency>

This solved my problems with dependencies running Apache Camel 2.24.1 on Java 12:
<dependency>
<groupId>javax.activation</groupId>
<artifactId>activation</artifactId>
<version>1.1.1</version>
</dependency>
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.3.1</version>
</dependency>
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-core</artifactId>
<version>2.3.0.1</version>
</dependency>
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-impl</artifactId>
<version>2.3.0.1</version>
</dependency>

Since JavaEE is now governed by https://jakarta.ee/, the new Maven coordinates as of 2.3.2 are:
https://eclipse-ee4j.github.io/jaxb-ri/#maven-artifacts
The first released jaxb.version is 2.3.2.
<properties>
<jaxb.version>2.3.2</jaxb.version>
</properties>
<dependency>
<groupId>jakarta.xml.bind</groupId>
<artifactId>jakarta.xml.bind-api</artifactId>
<version>${jaxb.version}</version>
</dependency>
<dependency>
<groupId>org.glassfish.jaxb</groupId>
<artifactId>jaxb-runtime</artifactId>
<version>${jaxb.version}</version>
</dependency>

I followed this URL and the below settings had really helped me. I use Java 10 with STS IDE in Macbook Pro. It works like a charm.
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.3.0</version>
</dependency>
<dependency>
<groupId>org.glassfish.jaxb</groupId>
<artifactId>jaxb-runtime</artifactId>
<version>2.3.0</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>javax.activation</groupId>
<artifactId>javax.activation-api</artifactId>
<version>1.2.0</version>
</dependency>

I encountered the same issue using Spring Boot 2.0.5.RELEASE on Java 11.
Adding javax.xml.bind:jaxb-api:2.3.0 alone did not fix the problem. I also had to update Spring Boot to the latest Milestone 2.1.0.M2, so I assume this will be fixed in the next official release.

As the official documentation states:
When upgrading you may face the following:
java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
Hibernate typically requires JAXB that’s no longer provided by default. You can
add the java.xml.bind module to restore this functionality with Java9
or Java10 (even if the module is deprecated).
As of Java11, the module is not available so your only option is to
add the JAXB RI (you can do that as of Java9 in place of adding the
java.xml.bind module:
Maven
<dependency>
<groupId>org.glassfish.jaxb</groupId>
<artifactId>jaxb-runtime</artifactId>
</dependency>
Gradle (build.gradle.kts):
implementation("org.glassfish.jaxb:jaxb-runtime")
Gradle (build.gradle)
implementation 'org.glassfish.jaxb:jaxb-runtime'
If you rather specify a specific version, take a look here:
https://mvnrepository.com/artifact/org.glassfish.jaxb/jaxb-runtime

Not an answer, but an addendum: I got because running groovysh (Groovy 2.4.13) if JAVA_HOME points to a Java 9 installation (java version "9.0.1" to be precise) fails abysmally:
java.lang.reflect.InvocationTargetException
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:107)
at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:129)
Caused by: java.lang.NoClassDefFoundError: Unable to load class groovy.xml.jaxb.JaxbGroovyMethods due to missing dependency javax/xml/bind/JAXBContext
at org.codehaus.groovy.vmplugin.v5.Java5.configureClassNode(Java5.java:400)
at org.codehaus.groovy.ast.ClassNode.lazyClassInit(ClassNode.java:277)
at org.codehaus.groovy.ast.ClassNode.getMethods(ClassNode.java:397)
...
..
.
..
...
at org.codehaus.groovy.tools.shell.Groovysh.<init>(Groovysh.groovy:135)
at org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:232)
at org.codehaus.groovy.tools.shell.Main.<init>(Main.groovy:66)
at org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:232)
at org.codehaus.groovy.tools.shell.Main.main(Main.groovy:163)
... 6 more
The solution was to:
Go to the JAXB Project at github.io ("JAXB is licensed under a dual license - CDDL 1.1 and GPL 2.0 with Class-path Exception")
Download jaxb-ri-2.3.0.zip
Unzip wherever you put your java infrastructure files (in my case, /usr/local/java/jaxb-ri/). Other solution may exist (maybe via SDKMAN, I dunno)
Make sure the jars in the lib subdirectory are on the CLASSPATH. I do it via a script started on bash startup, called /etc/profile.d/java.sh, where I added (among many other lines) the following loop:
Packed into a function...
function extend_qzminynshg {
local BASE="/usr/local/java"
for LIB in jaxb-api.jar jaxb-core.jar jaxb-impl.jar jaxb-jxc.jar jaxb-xjc.jar; do
local FQLIB="$BASE/jaxb-ri/lib/$LIB"
if [[ -f $FQLIB ]]; then
export CLASSPATH=$FQLIB:$CLASSPATH
fi
done
}
extend_qzminynshg; unset extend_qzminynshg
And it works!

you can use this dependency
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.3.0</version>
</dependency>

You only need 1 dependency:
dependencies {
implementation ("jakarta.xml.bind:jakarta.xml.bind-api:2.3.2")

For me in Java 11 and gradle this is what worked out:
plugins {
id 'java'
}
dependencies {
runtimeOnly 'javax.xml.bind:jaxb-api:2.3.1'
}

i want to give a simple and easy solution about this Exception , just downgrade the android studio version upto 4.1.1 or less. Make sure you don't have android studio arctic fox (2020.3.1) version , because latest version don't support old project of android.

OK, I have been having the same kind of issue, but I was using Java 8, and kept getting this error, I tried most of the solutions. but it turns out that my maven was still pointing to java 9 even-though I set the global Java version to 8, as soon as I fixed that it all worked.
For anybody who might have this kind of problem, check out How to fix Maven to use default Java (archived)

Ambiguous Maven dependency breaks Selenium

An excerpt from my project's dependency tree:
myproject
+- qxwebdriver-java 0.0.3
+- operadriver 1.5
| +- guava 14.0
+- selenium-java 2.52.0
+- selenium-remote-driver 2.52.0
| +- guava
+- selenium-safari-driver 2.52.0
Guava is required two times, via operadriver and selenium-remote-driver. In the latter case, dependency is declared without version. The project itself requires qxwebdriver-java and nothing more.
In this configuration, Safari driver does not work:
java.lang.NoSuchMethodError: com.google.common.base.Stopwatch.createStarted()Lcom/google/common/base/Stopwatch;
at org.openqa.selenium.safari.SafariDriverCommandExecutor.start(SafariDriverCommandExecutor.java:111)
This happens because the project's overall dependency on Guava resolves to 14.0 (via operadriver). However the required Stopwatch::createStarted() method has been introduced in Guava 19.0. Manually adding Guava 19.0 dependency to the project's POM fixes the issue.
But isn't this an issue of Selenium and/or Opera driver packaging? Do you think it should be reported upstream, or is my workaround the right way to do things like this in Maven?

This is a perfectly common situation in Java and Maven, and not a defect.
The correct solution is to add an exclusion in your pom. Something like this:
<dependency>
<groupId>com.opera</groupId>
<artifactId>operadriver</artifactId>
<version>1.5</version>
<exclusions>
<!-- outdated library conflicts with selenium-java -->
<exclusion>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-java</artifactId>
<version>[2.33.0,)</version>
<scope>test</scope>
</dependency>
Note that in rare cases - for example if guava version 19 deprecated something from version 14, that operadriver 1.5 depends on - doing this could break, in this case, operadriver.

Maven/Eclipse/Android upgrading API version

We have been using Android API version 17 in a project and wish to upgrade to API version 19 because the application runs on Android 4.4.
We use Maven as our build environment. I have replaced all the occurrences of SDK version 17 to 19 in our AndroidManifest.xml. But I am having problems upgrading to the 4.4 platform through Maven.
I used the Android SDK Deployer tool to push the android-4.4 package into my local Maven repository. I then replaced the reference to android-4.2 to android-4.4 in our 'parent' POM.xml:
<dependencyManagement>
<dependencies>
<dependency>
<!-- <groupId>com.google.android</groupId> OLD -->
<groupId>android</groupId>
<artifactId>android</artifactId>
<!-- <version>4.2.2_r2</version> OLD -->
<version>4.4.2_r4</version>
<scope>provided</scope>
</dependency>
This change seemed to introduce a conflict. Another dependency is bringing in version 2.1_r1 of android package which is conflicting with the new 4.4.2_r4 package:
Excerpt from 'mvn dependency:tree':
.
[INFO] +- com.github.tony19:logback-android-classic:jar:1.0.10-2:compile
[INFO] | \- com.github.tony19:apktool-lib:jar:1.4.4-3:compile
[INFO] | \- com.google.android:android:jar:2.1_r1:compile
[INFO] | +- org.khronos:opengl-api:jar:gl1.1-android-2.1_r1:compile
[INFO] | +- xerces:xmlParserAPIs:jar:2.6.2:compile
[INFO] | \- xpp3:xpp3:jar:1.1.4c:compile
I noticed that if I move the <dependency> declaration of the 4.4 package above the logback-android-classic dependency declaration in pom.xml then our module will use the 4.4 dependency. However I don't think this is a proper fix, and I am running into various issues building the project as a whole.
Can those more experienced with Maven please advise on the correct way to resolve this?

Going through each affected module and adding an exclusion to the logback-android-classic dependency seems to have resolved it:
<exclusions>
<exclusion>
<artifactId>android</artifactId>
<groupId>android</groupId>
</exclusion>
<exclusion>
<artifactId>android</artifactId>
<groupId>com.google.android</groupId>
</exclusion>
</exclusions>

Categories