java - Maven surefire could not find ForkedBooter class

Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.
Learn more about Collectives
Teams
Q&A for work
Connect and share knowledge within a single location that is structured and easy to search.
Learn more about Teams
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)
                I'm having this bug in clircle-ci. Surefire forks and forked vm prints the following message and exits:  "Error: Could not find or load main class org.apache.maven.surefire.booter.ForkedBooter". The massage is in target/surefire-reports/*.dumpstream . If you run maven with -X it prints the command line, you can try it and see the vm printing this message.
– Bruno Coutinho
                Oct 26, 2018 at 14:54
                Possible duplicate of Spring Boot fails to run maven-surefire-plugin ClassNotFoundException org.apache.maven.surefire.booter.ForkedBooter
– jediz
                Oct 29, 2018 at 19:54
                my solution was to stop using open-jdks of any version.  can't afford this kind of unreliability in something so foundational.
– Adrian M.
                Nov 2, 2018 at 20:32
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:
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).
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!
                @AdrianMadaras I did not get a new update so far, only the -2 version. There also was no announcement of a fixed upload yet, but its underway. You probably just re-upgraded to the known problematic version.
– Erich Schubert
                Oct 30, 2018 at 16:32
                I  just got the same issue on Ubuntu 18.04, using OpenJDK 10.0.2. Switching the JAVA_HOME to my 'java-9-oracle' install fixed it.
– Rob Audenaerde
                Oct 31, 2018 at 8:36
                Here’s the corresponding issue in the surefire-maven-plugin issue tracker: issues.apache.org/jira/browse/SUREFIRE-1588 (it’s still a bug in the Canonical/Debian backport of the relevant OpenJDK changes).
– mirabilos
                Oct 31, 2018 at 13:14
                Work around 1. doesn't make sense to me as that's the version I'm experiencing the issue on. Overriding the maven-surefire-plugin to not useSystemClassLoader also didn't work
– Edwin Diaz
                Nov 1, 2018 at 22:18
                You can try upgrading to surefire 3.0.0-M1, too. But 2 to a 3 milestone version can of course break other stuff.
– Erich Schubert
                Nov 8, 2018 at 16:34
<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.
                Enabling the system classloader is the worst practice due to you are running the tests in plugin process. The right practice is to upgrade the version of every plugin. Maven 3.7.0 will upgrade versions of all plugins which belong to the default life cycle. The Spring should not stick to the old versions and should not override them either. This causes unnecessary conflicts in responsibilities.
– tibor17
                May 17, 2020 at 9:02
                Use the latest Surefire version 3.0.0-M5. This was caused by PID checker. Now the checker is disabled and it can be manually enabled and configured.
– tibor17
                Oct 5, 2020 at 1:26
                According to the maven-surefire-plugin maintainer, all workarounds (this, setting forkCount to 0, or setting argLine globally) have problems and cannot be applied universally.
– mirabilos
                Nov 2, 2018 at 13:16
                Good find. But please include the actual workaround text in your post, or at least identify the link clearly as a stackoverflow link. I.e. the approach used by @markoorn is more helpful.
– nealmcb
                Nov 12, 2018 at 19:20
                Use the latest Surefire version 3.0.0-M5. This was caused by PID checker. Now the checker is disabled and it can be manually enabled and configured.
– tibor17
                Oct 5, 2020 at 1:25
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
                A breaking change labelled as a security fix is usually not introduced for no reason and so that someone tells on SO how to disable it... just sayin'
– berezovskyi
                Nov 28, 2018 at 15:41
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>
                This fails with the following warning: [WARNING] Expected root element 'settings' but found 'profile' (position: START_TAG seen <profile>... @1:9)  @ /home/nikolai/.m2/settings.xml, line 1, column 9
– Nikolai
                Nov 11, 2018 at 14:02
                @Nikolai The above snippet needs to be enclosed in <settings><profiles>...</profiles></settings>.
– qqx
                Nov 12, 2018 at 21:23
When using GitLab CI/CD with 3.6.0-jdk-8 image only the property below helped (without modifying pom.xml).
-Dsurefire.useSystemClassLoader=false
                This is again a bad practice. The right one is to upgrade the version. Always check the versions in Maven Central.
– tibor17
                May 17, 2020 at 9:12
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>
                Use the latest Surefire version 3.0.0-M5. This was caused by PID checker. Now the checker is disabled and it can be manually enabled and configured.
– tibor17
                Oct 5, 2020 at 1:25
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.
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
                This has the effect of not creating a new VM for running the tests, so the tests can possibly influence the main build VM.
– Paŭlo Ebermann
                Nov 6, 2018 at 10:25
                Use the latest Surefire version 3.0.0-M5. This was caused by PID checker. Now the checker is disabled and it can be manually enabled and configured.
– tibor17
                Oct 5, 2020 at 1:25
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.
                Why would anyone suggest to install a version without security patches?! Though other suggestions include skipping tests, huh.
– berezovskyi
                Nov 28, 2018 at 15:43
                You don't need to anymore :-) It's fixed. But for the meantime I had many java projects which I had to work on and my java runtime was nowhere exposed to any new code from outside. So there was a oversee-able risk that was Ok for me. It's everyone's own decision after all :-)
– flob
                Nov 28, 2018 at 15:58
                Actually you are right, I found that JDK devs walked back on that prop set by default: hg.openjdk.java.net/jdk/jdk/rev/f54dcfc5a5f8; but major version upgrade to surefire does not seem like the best fix to me, actually.
– berezovskyi
                Nov 28, 2018 at 15:59
                Absolutely! But the changes they had to make are throughout the whole codebase and very invasive. So a minor version change for this fix wouldn't be an option in surefire.
– flob
                Nov 28, 2018 at 16:04
                And unfortunately, 2.x is discontinued and we'll have to make a switch sooner than later: issues.apache.org/jira/browse/…
– berezovskyi
                Nov 28, 2018 at 16:05
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>
<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>
    <plugin>    
        <groupId>org.apache.maven.plugins</groupId> 
        <artifactId>maven-surefire-plugin</artifactId>  
        <configuration>
            <forkCount>0</forkCount>
        </configuration>
    </plugin>
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"
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
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",
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
                The problem comes from the latest jdk8 for debian, In my opinion it's better to "fix" the core problem than to try to work around it.
– Sylordis
                Oct 31, 2018 at 16:32
                The sha256 sound tricky and afraid you ? Actually other answer looks more like a work around, disable some feature from surefire, here it's just about use the last working docker image without changing your working pom or pipeline which is a work around.
– amdev
                Nov 2, 2018 at 8:21
        Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.