Maven surefire could not find ForkedBooter class

Question

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

Answer 1

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

Answer 2

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>

Answer 3

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>

Answer 4

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!

Answer 5

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

Answer 6

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.