Maven surefire could not find ForkedBooter class

JavaMavenMaven Surefire-Plugin

Java Problem Overview


Recently coming to a new project, I'm trying to compile our source code. Everything worked fine yesterday, but today is another story.

Every time I'm running mvn clean install on a module, once reaching the tests, it crashes into an error:

[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ recorder ---
[INFO] Surefire report directory: /lhome/code/recorder/target/surefire-reports
[INFO] Using configured provider org.apache.maven.surefire.junitcore.JUnitCoreProvider
[INFO] parallel='none', perCoreThreadCount=true, threadCount=0, useUnlimitedThreads=false, threadCountSuites=0,     threadCountClasses=0, threadCountMethods=0, parallelOptimized=true

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Error: Could not find or load main class org.apache.maven.surefire.booter.ForkedBooter

Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

and later on:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test (default-test) on project recorder: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test failed: The forked VM terminated without properly saying goodbye. VM crash or System.exit called?

I'm running on DebianĀ 9 (Stretch) 64-bits with OpenJDK 1.8.0_181, Maven 3.5.4, working behind my company proxy which I configured in my ~/.m2/settings.xml.

A strange thing it that the latest Surefire version is 2.22.1 if I remember correctly. I tried to specify the plugin version, but it does not get updated, otherwise there's no plugin version specification in any POM (parent, grand-parent or this one).

I managed to force Maven to change the Surefire version to the latest, but now it's even worse:

[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

[...]

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.22.1:test (default-test) on project recorder:     There are test failures.
[ERROR]
[ERROR] Please refer to /lhome/code/recorder/target/surefire-reports for the individual test results.
[ERROR] Please refer to dump files (if any exist) [date].dump, [date]-jvmRun[N].dump and [date].dumpstream.
[ERROR] The forked VM terminated without properly saying goodbye. VM crash or System.exit called?
[ERROR] Command was /bin/sh -c cd /lhome/code/recorder/ && /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java     '-javaagent:/lhome1/johndoe/.m2/repository/org/jacoco/org.jacoco.agent/0.7.4.201502262128/org.jacoco.agent-0.7.4.201502262128-runt    ime.jar=destfile=/lhome/code/recorder/target/jacoco.exec,append=true,includes=esa/*,excludes=**/api/**/*.class' -jar     /lhome/code/recorder/target/surefire/surefirebooter7426165516226884923.jar /lhome/code/recorder/target/surefire     2018-10-26T16-16-12_829-jvmRun1 surefire1721866559613511529tmp surefire_023400764142672144tmp
[ERROR] Error occurred in starting fork, check output in log
[ERROR] Process Exit Code: 1
[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: The forked VM terminated without properly saying goodbye.     VM crash or System.exit called?
[ERROR] Command was /bin/sh -c cd /lhome/code/recorder/ && /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java     '-javaagent:/lhome1/johndoe/.m2/repository/org/jacoco/org.jacoco.agent/0.7.4.201502262128/org.jacoco.agent-0.7.4.201502262128-runt    ime.jar=destfile=/lhome/code/recorder/target/jacoco.exec,append=true,includes=esa/*,excludes=**/api/**/*.class' -jar     /lhome/code/recorder/target/surefire/surefirebooter7426165516226884923.jar /lhome/code/recorder/target/surefire     2018-10-26T16-16-12_829-jvmRun1 surefire1721866559613511529tmp surefire_023400764142672144tmp
[ERROR] Error occurred in starting fork, check output in log
[ERROR] Process Exit Code: 1
[ERROR]     at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:669)
[ERROR]     at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:282)
[ERROR]     at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
[ERROR]     at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1183)
[ERROR]     at     org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1011)
[ERROR]     at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:857)
[ERROR]     at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
[ERROR]     at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
[ERROR]     at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
[ERROR]     at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
[ERROR]     at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
[ERROR]     at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
[ERROR]     at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
[ERROR]     at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
[ERROR]     at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
[ERROR]     at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
[ERROR]     at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
[ERROR]     at org.apache.maven.cli.MavenCli.execute(MavenCli.java:954)
[ERROR]     at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
[ERROR]     at org.apache.maven.cli.MavenCli.main(MavenCli.java:192)
[ERROR]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[ERROR]     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[ERROR]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[ERROR]     at java.lang.reflect.Method.invoke(Method.java:498)
[ERROR]     at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
[ERROR]     at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
[ERROR]     at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
[ERROR]     at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)

Java Solutions


Solution 1 - Java

To fix it (in 2018), update your openjdk to the latest version, at least 8u191-b12. In case this issue reappears in 2020, it is likely that the default behavior of openjdk was changed, and you will then need to update the maven surefire plugin.

This was a now fixed bug in the openjdk-8 package (behaviour deviates from upstream significantly without need; missing the upstream patch to revert back to disabling a security check) that you just upgraded to. But it is also a bug in the surefire plugin, SUREFIRE-1588, supposedly fixed in surefire 3.0.0-M1: it apparently is using absolute paths in a place where Java will in the future only allow relative path names (and Debian activated the future behavior already).

The package version 8u181-b13-2 states:

  • Apply patches from 8u191-b12 security update.

Note that 191-b12 != 181-b13. The 191-b12 security patches were just out a few days ago, and apparently the maintainers wanted to get them to you fast. Updating completely to 191-b12 will likely need additional testing (well, so should have this upload, apparently).

There had been several workaounds:

  1. You can install the previous package from snapshots.d.o instead. After downgrading, you can forbid the broken version (if you are using aptitude and not apt) using sudo aptitude forbid-version openjdk-8-jre-headless. For regular "apt" I didn't see a similar forbid mechanism, so you would likely need to use apt pinning to prevent this upgrade from being reinstalled (or you just keep on downgrading again, I hope this will be resolved soon).
  2. According to bug tracking, setting the property -Djdk.net.URLClassPath.disableClassPathURLCheck=true with any of the usual methods (e.g., JAVA_FLAGS) should also help. But I have not verified this myself. You can apparently even add the workaround to ~/.m2/settings.xml to get it enabled for all your Maven builds easily.

As you can see, bug tracking works, the issue was narrowed down, and a fixed package is available and a new version of the surefire plugin will come soon!

Solution 2 - Java

Set useSystemClassloader to false:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <configuration>
        <useSystemClassLoader>false</useSystemClassLoader>
    </configuration>
</plugin>

If you're not inheriting from a parent which has version defined for you (such as the Spring Boot starter) you'll need to define that as well.

Solution 3 - Java

I found this workaround and fixed my tests: configure the maven-surefire-plugin not to use the system classloader.

Solution 4 - Java

I have another workaround. Set the environment variable _JAVA_OPTIONS. I've used this for our TeamCity build agents and now our builds run fine.

_JAVA_OPTIONS=-Djdk.net.URLClassPath.disableClassPathURLCheck=true

Solution 5 - Java

I posted a more targeted variant of one of the above workarounds in JIRA. Add to ~/.m2/settings.xml:

<profile>
    <id>SUREFIRE-1588</id>
    <activation>
        <activeByDefault>true</activeByDefault>
    </activation>
    <properties>
        <argLine>-Djdk.net.URLClassPath.disableClassPathURLCheck=true</argLine>
    </properties>
</profile>

Solution 6 - Java

I had this issue in my GitLab CI build, which was using maven:3.5.4-jdk-8 Docker image.

Changing it to maven:3.5.4-jdk-8-alpine fixed the problem.

Solution 7 - Java

When using GitLab CI/CD with 3.6.0-jdk-8 image only the property below helped (without modifying pom.xml).

-Dsurefire.useSystemClassLoader=false

Solution 8 - Java

I followed this link https://maven.apache.org/surefire/maven-surefire-plugin/examples/class-loading.html and added the below plugin in pom.xml and it worked,

<project>
  [...]
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>2.22.1</version>
        <configuration>
          <useSystemClassLoader>false</useSystemClassLoader>
        </configuration>
      </plugin>
    </plugins>
  </build>
  [...]
</project>

Solution 9 - Java

For those searching for an answer related to Docker Maven: 3.5.x-jdk-8 on GitLab CI, see this GitHub issue.

It appears a 3.5.4-jdk-8 image resulted in upgrade to a minor Java version which somehow affects Surefire's forking mechanism.

Rolling back to 3.5.3-jdk-8 image fixed this for me on my GitLab CI server building Java 1.8 code with Surefire 2.20.1.

Solution 10 - Java

The suggestion above to set the property "-Djdk.net.URLClassPath.disableClassPathURLCheck=true" did NOT work for me, but setting the following does work OK:

-DforkCount=0

Solution 11 - Java

For Ubuntu: Install the latest version, it has this bug fixed

sudo apt-get update ; sudo apt-get dist-upgrade -y

Install the last working version (without security patches) without the bug.

sudo apt-get install openjdk-8-jdk-headless=8u181-b13-1 openjdk-8-jdk=8u181-b13-1  openjdk-8-jre=8u181-b13-1  openjdk-8-jre-headless=8u181-b13-1 openjdk-8-source=8u181-b13-1

If you missed that version, use the version before that:

sudo apt-get install openjdk-8-jdk-headless=8u162-b12-1 openjdk-8-jdk=8u162-b12-1  openjdk-8-jre=8u162-b12-1  openjdk-8-jre-headless=8u162-b12-1 openjdk-8-source=8u162-b12-1

Then use either pinning or watch out that you won't install the broken version.

Using -Djdk.net.URLClassPath.disableClassPathURLCheck=true didn't work for me wherever I had put that configuration. Somewhere in my integration-tests it always exited without the old Java version.

As mentioned by Erich it's a bug in the Debian package being too strict 911925 and the Surefire-plugin not acting according to the new rules SUREFIRE-1588.

Solution 12 - Java

I've added dependency to junit-jupiter-engine, and it worked.

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.22.1</version>
    <dependencies>
        <dependency>
            <groupId>org.junit.jupiter</groupId>
            <artifactId>junit-jupiter-engine</artifactId>
            <version>5.4.0</version>
        </dependency>
    </dependencies>
</plugin>

Solution 13 - Java

Adding this to the maven-surefire-plugin I resolved the problem:

    <plugin>    
        <groupId>org.apache.maven.plugins</groupId> 
        <artifactId>maven-surefire-plugin</artifactId>  
        <configuration>
            <forkCount>0</forkCount>
        </configuration>
    </plugin>

Solution 14 - Java

It's still an issue for surefire - v2.22.2 with maven:3.6-jdk-8-alpine. To fix the issue, add the below code to pom.xml (as maven plugin)

...
<plugin>    
    <groupId>org.apache.maven.plugins</groupId> 
    <artifactId>maven-surefire-plugin</artifactId>  
    <configuration>
        <forkCount>0</forkCount>
    </configuration>
</plugin>
...

Solution 15 - Java

I recently setup maven job on Jenkins and got stuck into the same problem. I took the suggestion to modify the JAVA env variable and confirm the issue resolved. This is how I tested.

Becomes "jenkins" user and change folder to workspace project name that you setup for the job.

 $ _JAVA_OPTIONS=-Djdk.net.URLClassPath.disableClassPathURLCheck=true mvn clean install -U

 $ lsb_release -rd
 Description:	Ubuntu 16.04.5 LTS
 Release:	16.04

 $ mvn -v
 Apache Maven 3.3.9
 Maven home: /usr/share/maven
 Java version: 1.8.0_181, vendor: Oracle Corporation
 Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
 Default locale: en_US, platform encoding: UTF-8
 OS name: "linux", version: "4.4.0-131-generic", arch: "amd64", family: "unix"

Solution 16 - Java

Basically is an incompatibility between JDK version and maven-surefire plugin version, in my case, JDK 11.0.5 doesn't work with surefire 3.0.0-M4, I had to switch to 3.0.0-M3 and it worked. setting forkCount to 0 doesn't fix the issue because it breaks the Jacoco report.

Solution 17 - Java

I uninstalled the JDK that comes in the repositories:

$ sudo apt purge openjdk-8-jdk

$ sudo apt autoremove

Then I deleted the JAVA_HOME environment variable. Mine was set in my .bashrc.

Then I reinstalled it through SDKMAN:

$ sdk install java 8.0.181-zulu

From their site:

> SDKMAN! is a tool for managing parallel versions of multiple Software Development Kits on most Unix based systems. It provides a convenient Command Line Interface (CLI) and API for installing, switching, removing and listing Candidates.

To see other versions of the JDK to install, use:

$ sdk list java

Solution 18 - Java

I was facing the same issue with gitlab ci, changing maven image from maven:3-jdk-8 to maven:3.6.0-jdk-8-alpine seems to fix the issue. Btw I also tested with maven:3.6.0-jdk-8 but it didn't work neither.

Solution 19 - Java

For me, in Visual Studio Code

I did not do any changes in the pom.xml file or updated any dependency versions
Adding this line to settings.json of Visual Studio Code solved the problem.

"maven.executable.options": "-DforkCount=0",

Solution 20 - Java

If like me you have issues in your pipeline (for me it's in GitLab, but whatever) and if you are using a Maven JDK 8 Docker image.

You can replace

image: maven:3.5.4-jdk-8

by the last working build

image: maven@sha256:b37da91062d450f3c11c619187f0207bbb497fc89d265a46bbc6dc5f17c02a2b

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionSylordisView Question on Stackoverflow
Solution 1 - JavaErich SchubertView Answer on Stackoverflow
Solution 2 - JavaMarkoornView Answer on Stackoverflow
Solution 3 - Javauser3090935View Answer on Stackoverflow
Solution 4 - JavaMichaelView Answer on Stackoverflow
Solution 5 - JavaJesse GlickView Answer on Stackoverflow
Solution 6 - JavabrunobastosgView Answer on Stackoverflow
Solution 7 - JavaGrzesView Answer on Stackoverflow
Solution 8 - JavaArunkumar ArjunanView Answer on Stackoverflow
Solution 9 - JavaSimon DiemertView Answer on Stackoverflow
Solution 10 - Javafarid g.View Answer on Stackoverflow
Solution 11 - JavaflobView Answer on Stackoverflow
Solution 12 - JavaAdi BaboianuView Answer on Stackoverflow
Solution 13 - JavaRuben RomeroView Answer on Stackoverflow
Solution 14 - JavaKimchiManView Answer on Stackoverflow
Solution 15 - JavaBoonchu NgampairoijpibulView Answer on Stackoverflow
Solution 16 - Javaapolo884View Answer on Stackoverflow
Solution 17 - JavajumpnettView Answer on Stackoverflow
Solution 18 - JavamndeveciView Answer on Stackoverflow
Solution 19 - JavaParth ManaktalaView Answer on Stackoverflow
Solution 20 - JavaamdevView Answer on Stackoverflow