Re: Let's move Surefire project to JAVA 9. Surefire and Failsafe stop working on latest versions of Windows due to missing wmic.

[Romain Manni-Bucau]

I disagree Tibor, makes years people let you mess up surefire, complain but
let you do cause at the end you do maintain it but nobody is happy with
your changes nor surefire state so think you can also reverse the names and
your mail just works.

Don't shout too strong cause you have your view, it works, but in maven we
have very heterogeneous as background and business so different views can
work too and technically surefire is almost impossible to defend the way it
is done today, this is why it would be sane to just drop most of it for
maven 4.

Even this particular bug you speak about, it is 100% useless as soon as you
do use forks instead of remoting except on windows - so yes on UNIx it is a
bug to impl it as you did, and I recall people were not shocked to kill
surefire forks on windows 10+ years ago just cause this is how it is on
windows. Now on CI we do have containers so at the end the feature is
overkill, discussable and useless so maybe we should just remove it?

Romain Manni-Bucau
@rmannibucau  | .NET Blog
 | Blog  | Old
Blog  | Github
 | LinkedIn
 | Book

Javaccino founder (Java/.NET service - contact via linkedin)


Le mer. 18 févr. 2026 à 03:13, Tibor Digaňa  a
écrit :

> Hello Herve,
>
> I would like to discuss this personally with you, Olivier, Tamas and
> Michaelo.
> 1. we were discussing the Issue opened by customer on GH. There I wrote
> that I will make an analysis and everybody should wait because we do not
> know the fix yet. There we needed to make the analysis, I did it, and I
> provided the workaround for the customer so that we don't need to have the
> real fix so fast.
> 2. I opened a discussion where exactly these things needed to be shown.
> After 5 days Olivier pushed a PR with unnecessarily huge changes and
> without the outcome of the analysis and without the proposed solution.
>
> This is my problem:
> We should not proactively commit something, otherwise we do not know what
> we are doing without having the analysis and a proposed solution.
> Sorry but I cannot accept this style of development when we ignore 1.
> Analysis and 2. Proposed solution on the Mailing list.
> How it would look like if Maven pushed changes ignoring the others. It
> would be a mess. This happened in 2016 with version 3.4.0 when the
> development wasn't coordinated and we found out the problem after months
> when the build process crashed, we reverted the master, we recalled and
> re-evaluated each commit and finally we lost a lot of time.
> Surefire is in similar situation with Olivier, because he is pushing some
> code straight ahead and he is ignoring you. He does not care that we need
> to clarify something here. Instead I can see tons of changed files instead
> of one class/file. I know it because I was author of it.
> We need to be better coordinated, and as I spoke with Tamas at Apero, it's
> not only Surefire but the Maven itself needs to be coordinated and
> obviously we have this problem. Each sub-project is different but its there
> and it is special with Olivier who has his ... plans ignoring you even if
> you asked him for cooperation, but no, he does not care that you exits. And
> the worst is the code because it goes to a disaster, JUnit5 is unstable,
> Reporters have HACKS and I have to make an investment to clarify over and
> over again why it's bad and how to fix it but the guy does not want to
> understand it and instead he permanently says "delete" "delete" and
> "delete" - it's like a business and not the Open source. I don't remember
> this status before, because it was perfect few years ago but today the
> cooperation with Olivier does not work. I remember him in Jenkins when he
> helped me but today, no, absolutely no way, only his way his line really
> like a business, it really smells by a business. I still have this feeling
> because it's not normal whats happening. I don't remember this before. It's
> not good! I m really frustrated from this cooperation. I can give you my
> knowledge, my power, my energy, my experiences, my everything, but it is
> not applicable somehow because there's no reaction on the other side.
>
> Cheers
> Tibor
>
> On Mon, Feb 16, 2026 at 12:33 AM Hervé Boutemy 
> wrote:
>
> > I'm not going in technical details: I'm not in Surefire
> > but reverting a reviewed PR without any review is not an option
> >
> > @Tibor
> > please revert then discuss
> > not the opposite
> >
> > thanks
> >
> > Hervé
> >
> >
> > Le dimanche 15 février 2026, 12:01:07 CET Romain Manni-Bucau a écrit :
> > > Hi Tibor,
> > >
> > > there is no way you violate the community process like that.
> > > Olivier did address most of the issues, he did pass the review process
> > and
> > > while discussion was

Re: Let's move Surefire project to JAVA 9. Surefire and Failsafe stop working on latest versions of Windows due to missing wmic.

[Tibor Digaňa]

Hello Herve,

I would like to discuss this personally with you, Olivier, Tamas and
Michaelo.
1. we were discussing the Issue opened by customer on GH. There I wrote
that I will make an analysis and everybody should wait because we do not
know the fix yet. There we needed to make the analysis, I did it, and I
provided the workaround for the customer so that we don't need to have the
real fix so fast.
2. I opened a discussion where exactly these things needed to be shown.
After 5 days Olivier pushed a PR with unnecessarily huge changes and
without the outcome of the analysis and without the proposed solution.

This is my problem:
We should not proactively commit something, otherwise we do not know what
we are doing without having the analysis and a proposed solution.
Sorry but I cannot accept this style of development when we ignore 1.
Analysis and 2. Proposed solution on the Mailing list.
How it would look like if Maven pushed changes ignoring the others. It
would be a mess. This happened in 2016 with version 3.4.0 when the
development wasn't coordinated and we found out the problem after months
when the build process crashed, we reverted the master, we recalled and
re-evaluated each commit and finally we lost a lot of time.
Surefire is in similar situation with Olivier, because he is pushing some
code straight ahead and he is ignoring you. He does not care that we need
to clarify something here. Instead I can see tons of changed files instead
of one class/file. I know it because I was author of it.
We need to be better coordinated, and as I spoke with Tamas at Apero, it's
not only Surefire but the Maven itself needs to be coordinated and
obviously we have this problem. Each sub-project is different but its there
and it is special with Olivier who has his ... plans ignoring you even if
you asked him for cooperation, but no, he does not care that you exits. And
the worst is the code because it goes to a disaster, JUnit5 is unstable,
Reporters have HACKS and I have to make an investment to clarify over and
over again why it's bad and how to fix it but the guy does not want to
understand it and instead he permanently says "delete" "delete" and
"delete" - it's like a business and not the Open source. I don't remember
this status before, because it was perfect few years ago but today the
cooperation with Olivier does not work. I remember him in Jenkins when he
helped me but today, no, absolutely no way, only his way his line really
like a business, it really smells by a business. I still have this feeling
because it's not normal whats happening. I don't remember this before. It's
not good! I m really frustrated from this cooperation. I can give you my
knowledge, my power, my energy, my experiences, my everything, but it is
not applicable somehow because there's no reaction on the other side.

Cheers
Tibor

On Mon, Feb 16, 2026 at 12:33 AM Hervé Boutemy 
wrote:

> I'm not going in technical details: I'm not in Surefire
> but reverting a reviewed PR without any review is not an option
>
> @Tibor
> please revert then discuss
> not the opposite
>
> thanks
>
> Hervé
>
>
> Le dimanche 15 février 2026, 12:01:07 CET Romain Manni-Bucau a écrit :
> > Hi Tibor,
> >
> > there is no way you violate the community process like that.
> > Olivier did address most of the issues, he did pass the review process
> and
> > while discussion was still ongoing there is no consensus on a revert nor
> > discusion so think we should revert the revert, finish the discussion if
> > needed and move forward.
> >
> > Side note: it is ok to be alone against the community in idea, it is
> wrong
> > to be in acts.
> >
> > Just my 2cts but this can't be right @asf.
> >
> > Romain Manni-Bucau
> > @rmannibucau  | .NET Blog
> >  | Blog 
> |
> > Old Blog  | Github
> >  | LinkedIn
> >  | Book
> > <
> https://www.packtpub.com/en-us/product/java-ee-8-high-performance-978178847
> > 3064> Javaccino founder (Java/.NET service - contact via linkedin)
> >
> > Le dim. 15 févr. 2026 à 04:02, Olivier Lamy  a écrit :
> > > Hi,
> > >
> > > I was surprised to see these changes reverted, as they were addressing
> > > issues affecting a significant number of Windows users.
> > > The PRs in question resolved problems for users running on Windows
> > > without WMIC but using Java 9+. They also aimed to improve the current
> > > behaviour and incorporate points that had previously been raised
> > > during review.
> > > The compatibility concern mentioned appears to affect a relatively
> > > narrow subset of users: Java 8 users who rely on WMIC without
> > > PowerShell installed.
> > > While it is important to consider such edge cases, there may be ways
> > > to mitigate the impact without fully reverting improvements that
> > > benefit a broader group of users.
> > > For user

Re: Let's move Surefire project to JAVA 9. Surefire and Failsafe stop working on latest versions of Windows due to missing wmic.

[Tibor Digaňa]

Hi all,

We started this discussion 8 days ago, it is still pending.

Sylwester L. asked me to open the discussion here 8 days ago, so I did. We
still have not made any consensus, and Olivier proactively pushed his work
into master, I reverted his change because we still have not finished the
analysis and a proposal. Due to there are two issues and not one, both must
be fixed altogether and everybody has to understand what we are doing, why
and how.

@Olivier Lamy, I require from you to inform me about everything what you
are doing in this project and you will invite me in every PR you
participate on and this way we will discuss together and we we collaborate
together.

There are several technical notices on my side:

1. We have also customers with old Windows systems: Windows XP, Windows
Server.
2. It is not true that the PowerShell is the only solution because not
everybody wants to install it nor installed it yet.
3. It is true that using OS-naturally native commands we are significantly
mitigating the risk (the risk that some native binary is not recognized).
4. It is true that the *ProcessHandle* [1] is *totally avoiding this issue*.
Unlikely the PS or WMIC or PowerShell commands which are only at the
mitigation level - there is always some risk but it is minimum.
5. It is true that using a kind of Java reflection (or a modern
*MethodHandle* [2]) we can call *ProcessHandle* [1] without any problem
even on Java 8 build process of this project (customer's build process is
different story - there *ProcessHandle* can be activated).
6. If we do not want to switch to Java 9, I am fine with that, but then we
have to continue in the risk mitigation and we should not push the customer
to something he does not like and it is reinstallation of old systems with
PowerShell (which might not be installable). In this case adding PowerShell
is okay but we have to keep WMIC for old Windows systems, and PS for *Nix
systems. Due to the Java 9 API is simple, and it is simple to call (in
principal) *ProcessHandle.of(PPID).isAlive()* via the reflection - we have
these experiences, we can switch from *risk mitigation* to a *guarantee*.
Since of Maven 4, we can delete all of these PowerShell, WMIC, PS commands
and call *ProcessHandle.of(PPID).isAlive() *without reflection - trivial.
7. Additionally, we didn't say that there is one more problem. The customer
would not recognize this issue if the native commands fallback-ed to the
PING mechanism. There is a bug, and it does not matter if you add
PowerShell or the trick with Java 9. It does not matter! This is missing,
still in the code and that's the reason why yesterday I made the analysis
of these commands.

[1]:
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ProcessHandle.html
[2]:
https://docs.oracle.com/javase/8/docs/api/java/lang/invoke/MethodHandle.html


Solution proposal:

After this analysis, it's clear that the Java8-based projects have to use
the native commands. WMIC has to fallback to PowerShell if IOException is
thrown (Chain of Responsibility design pattern). PS command would stay on
*Nix platforms. The Java 9 process checker takes the precedense on Java 9+,
this must be implemented as Strategy pattern and the appropriate object
would be selected by platform conditions. Regarding the point (7) the
*ProcessChecker* must be fixed and the handler of the execute method as
well in order to fallback to PING. No IT deleted. Only two unit tests added
for PowerShell - Windows and *ProcessHandle* - Java9.

I am very sorry for the inconvenience.

This would require the reactions, and personal talks.

I would open Apero beer meeting on every last Tuestady via Google Meet
where we can friendly talk about the Maven in general. We somehow stopped
this activity last year and it's the time to continue with this very nice
activity again. I will send the appointment tomorrow.


Cheers

Tibor17



On Sat, Feb 7, 2026 at 1:21 AM Tibor Digaňa  wrote:

> Hi all,
>
> I would like to have your opinion regarding this issue reported on GitHub:
> "Surefire and Failsafe stop working on latest versions of Windows due to
> missing wmic"
> Please see the link here
> https://github.com/apache/maven-surefire/issues/3176
>
> I am the author who developed the PPID Process Checker. When I worked on
> it together with Michael Osipov, we reached a consensus. It was a very nice
> personal collaboration, and now I would be glad to have this guy back in
> the active Maven Team again :-)
> That time we used Java 7 or Java 8, or even both, however Java 9 was
> available in the world. We could not use the Java 9 however it could really
> help us. Therefore we decided to call the system library "wmic" on Windows,
> and "ps" on *Nix world, and not Java 9.
>
> Due to the Microsoft Windows removed "wmic", I am open to move complete
> Surefire project under Java 9.
>
> I remember how problematic life it was when we had to support both Java 7
> and Java 8 at the same time. I do not want t

Re: Let's move Surefire project to JAVA 9. Surefire and Failsafe stop working on latest versions of Windows due to missing wmic.

[Tibor Digaňa]

This is the test result on Ubuntu. The outcome is that the errorCode is
irelevant for us, and the command is crashed on unknown binary if started
command throws IOException and this is important in order to continue with
PING after the first crash.

1. This is the case when the PID exists but the command is not found on the
system:
Let's rename ps to psx which simulates that the ps does not exist.
java.io.IOException: Cannot run program "psx": Exec failed, error: 2 (No
such file or directory)
This behavior is the same in Windows.

2. This is case when PID does not exists but the command exists:
No values, no numbers because the process does not exist.
$ ps -p 3026
PID TTY  TIME CMD
ProcessBuilder.waitFor() returns exit code 1. This behavior is
different from Windows which returns exit code 0. In both cases
the result values are missing.

3. Finally, the happy case:
Found a process by PID 3025:
$ ps -p 3025
 PID TTY  TIME CMD
3025 ?00:03:18 idea`





On Fri, Feb 13, 2026 at 10:43 PM Tibor Digaňa 
wrote:

> It does not matter if you are calling WMIC or PowerShell because both
> might be unavailable on the system.
> The point here is that I designed the utility so that the first crash of
> the native command should fallback to PING which is platform independent
> mechanism.
>
> I downloaded the appliance `WinDev2407Eval.ova` and created VM in
> VirtualBox. It contains Microsoft Windows 11 Enterprise Evaluation. WMIC
> was officially deprecated in Windows 10, it should not be shipped with
> Windows 11 (22H2+) but the reality is different because my Windows 11
> Enterprise Evaluation (22H2).
>
> PowerShell is not installed and enabled by default:
> `pwsh --version`
> ```'pwsh' is not recognized as an internal or external command,
> operable program or batch file.```
>
> Windows 11 contains `tasklist.exe` but Windows XP Home does not have
> `tasklist.exe` binary installed but XP Professional contains tasklist.
>
> `$ wmicx process where ProcessId=3092`
> ```No Instance(s) Available.
> java.io.IOException: Cannot run program "wmicx": CreateProcess error=2,
> The system cannot find the file specified```
>
> `$ tasklist /M /FI "pid eq 3093"`
> ```INFO: No tasks are running which match the specified criteria.```
>
> `$ wmic process where ProcessId=3093`
> ProcessBuilder.waitFor() returns exit code 0
>
>
> `$ tasklist /M /FI "pid eq 3092"`
> ```Image NamePID Modules
>  
> svchost.exe  3092 N/A```
>
> `$ wmic process where ProcessId=3092`
> ```Caption  ProcessId
> svchost.exe  3092```
> ProcessBuilder.waitFor() returns exit code 0
>
> On Fri, Feb 13, 2026 at 10:42 PM Tibor Digaňa 
> wrote:
>
>> Actually, there is one more thing!   Nobody said that.
>> The little tiny code was designed so, that, when either PS or WMIC fails,
>> then the PING is the fallback.
>> It's different when the command fails due to the process with the
>> particular PID does not exist, and it is different story when the WMIC or
>> PS itself has a serious system problem.
>> So, maybe it is wrong to start coding a fix if you do not have Windows.
>> First you must have experiences with this and understand what's going on.
>> The Forked JVM is immediately exited because the first check fails eagerly
>> and it could not fallback to the PING mechanism.
>> Most probably this is the problem.
>>
>> On Sat, Feb 7, 2026 at 1:21 AM Tibor Digaňa 
>> wrote:
>>
>>> Hi all,
>>>
>>> I would like to have your opinion regarding this issue reported on
>>> GitHub:
>>> "Surefire and Failsafe stop working on latest versions of Windows due to
>>> missing wmic"
>>> Please see the link here
>>> https://github.com/apache/maven-surefire/issues/3176
>>>
>>> I am the author who developed the PPID Process Checker. When I worked on
>>> it together with Michael Osipov, we reached a consensus. It was a very nice
>>> personal collaboration, and now I would be glad to have this guy back in
>>> the active Maven Team again :-)
>>> That time we used Java 7 or Java 8, or even both, however Java 9 was
>>> available in the world. We could not use the Java 9 however it could really
>>> help us. Therefore we decided to call the system library "wmic" on Windows,
>>> and "ps" on *Nix world, and not Java 9.
>>>
>>> Due to the Microsoft Windows removed "wmic", I am open to move complete
>>> Surefire project under Java 9.
>>>
>>> I remember how problematic life it was when we had to support both Java
>>> 7 and Java 8 at the same time. I do not want to support two Java versions
>>> again.
>>> It would be easier for us to get a confidence from the Maven community
>>> and switch to Java 9 directly.
>>> I hope we would get an exception in the list of Maven plugins.
>>>
>>> BTW, One more remark. There are strengths to destroy this project. Let's
>>> ignore these strengths. We can prevent from this happening if we are
>>> positive and we are friendly working together.
>>>
>>>
>>> Cheers
>>> Tibor17
>>>
>>

Re: Let's move Surefire project to JAVA 9. Surefire and Failsafe stop working on latest versions of Windows due to missing wmic.

[Tibor Digaňa]

It does not matter if you are calling WMIC or PowerShell because both might
be unavailable on the system.
The point here is that I designed the utility so that the first crash of
the native command should fallback to PING which is platform independent
mechanism.

I downloaded the appliance `WinDev2407Eval.ova` and created VM in
VirtualBox. It contains Microsoft Windows 11 Enterprise Evaluation. WMIC
was officially deprecated in Windows 10, it should not be shipped with
Windows 11 (22H2+) but the reality is different because my Windows 11
Enterprise Evaluation (22H2).

PowerShell is not installed and enabled by default:
`pwsh --version`
```'pwsh' is not recognized as an internal or external command,
operable program or batch file.```

Windows 11 contains `tasklist.exe` but Windows XP Home does not have
`tasklist.exe` binary installed but XP Professional contains tasklist.

`$ wmicx process where ProcessId=3092`
```No Instance(s) Available.
java.io.IOException: Cannot run program "wmicx": CreateProcess error=2,
The system cannot find the file specified```

`$ tasklist /M /FI "pid eq 3093"`
```INFO: No tasks are running which match the specified criteria.```

`$ wmic process where ProcessId=3093`
ProcessBuilder.waitFor() returns exit code 0


`$ tasklist /M /FI "pid eq 3092"`
```Image NamePID Modules
 
svchost.exe  3092 N/A```

`$ wmic process where ProcessId=3092`
```Caption  ProcessId
svchost.exe  3092```
ProcessBuilder.waitFor() returns exit code 0

On Fri, Feb 13, 2026 at 10:42 PM Tibor Digaňa 
wrote:

> Actually, there is one more thing!   Nobody said that.
> The little tiny code was designed so, that, when either PS or WMIC fails,
> then the PING is the fallback.
> It's different when the command fails due to the process with the
> particular PID does not exist, and it is different story when the WMIC or
> PS itself has a serious system problem.
> So, maybe it is wrong to start coding a fix if you do not have Windows.
> First you must have experiences with this and understand what's going on.
> The Forked JVM is immediately exited because the first check fails eagerly
> and it could not fallback to the PING mechanism.
> Most probably this is the problem.
>
> On Sat, Feb 7, 2026 at 1:21 AM Tibor Digaňa 
> wrote:
>
>> Hi all,
>>
>> I would like to have your opinion regarding this issue reported on GitHub:
>> "Surefire and Failsafe stop working on latest versions of Windows due to
>> missing wmic"
>> Please see the link here
>> https://github.com/apache/maven-surefire/issues/3176
>>
>> I am the author who developed the PPID Process Checker. When I worked on
>> it together with Michael Osipov, we reached a consensus. It was a very nice
>> personal collaboration, and now I would be glad to have this guy back in
>> the active Maven Team again :-)
>> That time we used Java 7 or Java 8, or even both, however Java 9 was
>> available in the world. We could not use the Java 9 however it could really
>> help us. Therefore we decided to call the system library "wmic" on Windows,
>> and "ps" on *Nix world, and not Java 9.
>>
>> Due to the Microsoft Windows removed "wmic", I am open to move complete
>> Surefire project under Java 9.
>>
>> I remember how problematic life it was when we had to support both Java 7
>> and Java 8 at the same time. I do not want to support two Java versions
>> again.
>> It would be easier for us to get a confidence from the Maven community
>> and switch to Java 9 directly.
>> I hope we would get an exception in the list of Maven plugins.
>>
>> BTW, One more remark. There are strengths to destroy this project. Let's
>> ignore these strengths. We can prevent from this happening if we are
>> positive and we are friendly working together.
>>
>>
>> Cheers
>> Tibor17
>>
>

Re: Let's move Surefire project to JAVA 9. Surefire and Failsafe stop working on latest versions of Windows due to missing wmic.

[Tibor Digaňa]

Actually, there is one more thing!   Nobody said that.
The little tiny code was designed so, that, when either PS or WMIC fails,
then the PING is the fallback.
It's different when the command fails due to the process with the
particular PID does not exist, and it is different story when the WMIC or
PS itself has a serious system problem.
So, maybe it is wrong to start coding a fix if you do not have Windows.
First you must have experiences with this and understand what's going on.
The Forked JVM is immediately exited because the first check fails eagerly
and it could not fallback to the PING mechanism.
Most probably this is the problem.

On Sat, Feb 7, 2026 at 1:21 AM Tibor Digaňa  wrote:

> Hi all,
>
> I would like to have your opinion regarding this issue reported on GitHub:
> "Surefire and Failsafe stop working on latest versions of Windows due to
> missing wmic"
> Please see the link here
> https://github.com/apache/maven-surefire/issues/3176
>
> I am the author who developed the PPID Process Checker. When I worked on
> it together with Michael Osipov, we reached a consensus. It was a very nice
> personal collaboration, and now I would be glad to have this guy back in
> the active Maven Team again :-)
> That time we used Java 7 or Java 8, or even both, however Java 9 was
> available in the world. We could not use the Java 9 however it could really
> help us. Therefore we decided to call the system library "wmic" on Windows,
> and "ps" on *Nix world, and not Java 9.
>
> Due to the Microsoft Windows removed "wmic", I am open to move complete
> Surefire project under Java 9.
>
> I remember how problematic life it was when we had to support both Java 7
> and Java 8 at the same time. I do not want to support two Java versions
> again.
> It would be easier for us to get a confidence from the Maven community and
> switch to Java 9 directly.
> I hope we would get an exception in the list of Maven plugins.
>
> BTW, One more remark. There are strengths to destroy this project. Let's
> ignore these strengths. We can prevent from this happening if we are
> positive and we are friendly working together.
>
>
> Cheers
> Tibor17
>

Re: Let's move Surefire project to JAVA 9. Surefire and Failsafe stop working on latest versions of Windows due to missing wmic.

[Sylwester Lachiewicz]

Question - do we want Surefire 4.x to require Java 11. Then 5.0 to require
Java 17&Maven 4?

Do we have plans to upgrade our Maven parent pom to require Java 11 (ASF or
only Maven) - as this mean that would be good to prepare all our projects
to use tool chains. We want to keep all other projects to be still java 8,
right?

Sylwester

czw., 12 lut 2026, 06:58 użytkownik Benjamin Marwell 
napisał:

> If someone is stuck on Maven 3.5.x for one or the other reason, they won't
> be able to upgrade surefire anyway... They haven't been able to update for
> at least a year.
>
> They can just keep their setup.
>
> I see no reason why this would stop us from requiring Java 9+ in a later
> version of surefire.
>
> - Ben
>
>
> On 12 February 2026 01:39:11 CET, Greg Chabala 
> wrote:
> >> The fact no one wants to go through the hazzle of setting up toolchains
> >doesn't count for me.
> >
> >Have you tried using it? There are still rough edges to be found and
> >corrected, particularly for older JDK support.
> >
> >I'm still waiting for a release with
> >https://github.com/apache/maven-toolchains-plugin/issues/113 in it.
> >
> >Also, a reminder that users participating on the mailing list are a tiny
> >fraction of the actual user population. One cannot know what all the users
> >requirements are. It's reasonable to assume that some are stuck on JDK8
> for
> >good reason, and 'JDK25 can build JDK8 conforming classfiles' is not a
> >solution.
> >
> >I continue to be surprised by what I discover in the wild, e.g. 'Why are
> >you running Maven 3.5.4?', 'Why are all your plugins 2.X versions?'. Just
> >getting folks to realize that upgrading the core tool does not mean they
> >have a 'Maven 3 build'.
> >
> >If Surefire stops working on JDK8, it should be a major version bump, just
> >for clarity.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Let's move Surefire project to JAVA 9. Surefire and Failsafe stop working on latest versions of Windows due to missing wmic.

[Benjamin Marwell]

If someone is stuck on Maven 3.5.x for one or the other reason, they won't be 
able to upgrade surefire anyway... They haven't been able to update for at 
least a year.

They can just keep their setup.

I see no reason why this would stop us from requiring Java 9+ in a later 
version of surefire.

- Ben


On 12 February 2026 01:39:11 CET, Greg Chabala  wrote:
>> The fact no one wants to go through the hazzle of setting up toolchains
>doesn't count for me.
>
>Have you tried using it? There are still rough edges to be found and
>corrected, particularly for older JDK support.
>
>I'm still waiting for a release with
>https://github.com/apache/maven-toolchains-plugin/issues/113 in it.
>
>Also, a reminder that users participating on the mailing list are a tiny
>fraction of the actual user population. One cannot know what all the users
>requirements are. It's reasonable to assume that some are stuck on JDK8 for
>good reason, and 'JDK25 can build JDK8 conforming classfiles' is not a
>solution.
>
>I continue to be surprised by what I discover in the wild, e.g. 'Why are
>you running Maven 3.5.4?', 'Why are all your plugins 2.X versions?'. Just
>getting folks to realize that upgrading the core tool does not mean they
>have a 'Maven 3 build'.
>
>If Surefire stops working on JDK8, it should be a major version bump, just
>for clarity.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Let's move Surefire project to JAVA 9. Surefire and Failsafe stop working on latest versions of Windows due to missing wmic.

[Greg Chabala]

> The fact no one wants to go through the hazzle of setting up toolchains
doesn't count for me.

Have you tried using it? There are still rough edges to be found and
corrected, particularly for older JDK support.

I'm still waiting for a release with
https://github.com/apache/maven-toolchains-plugin/issues/113 in it.

Also, a reminder that users participating on the mailing list are a tiny
fraction of the actual user population. One cannot know what all the users
requirements are. It's reasonable to assume that some are stuck on JDK8 for
good reason, and 'JDK25 can build JDK8 conforming classfiles' is not a
solution.

I continue to be surprised by what I discover in the wild, e.g. 'Why are
you running Maven 3.5.4?', 'Why are all your plugins 2.X versions?'. Just
getting folks to realize that upgrading the core tool does not mean they
have a 'Maven 3 build'.

If Surefire stops working on JDK8, it should be a major version bump, just
for clarity.

Re: Let's move Surefire project to JAVA 9. Surefire and Failsafe stop working on latest versions of Windows due to missing wmic.

[Benjamin Marwell]

We discussed this a LOT in the past years.

No one is stopping you from developing on Win10, install the utility yourself, 
developing on Linux or Mac instead.

Furthermore, you can compile to 8 when running Maven with 11,17,21,25.
You can use toolchains.

After building, no one is stopping you from acceptance testing or running your 
artifact on your supported Java 8 VM. 

I really don't see why you want to couple the Maven Runtime so hard to tests 
you can run on 8. The release flag even does API checks for you. 

So, what's your hard requirement to keep surefire on 8? The fact no one wants 
to go through the hazzle of setting up toolchains doesn't count for me.

- Ben



On 11 February 2026 15:24:47 CET, Elliotte Rusty Harold  
wrote:
>On Wed, Feb 11, 2026 at 2:09 PM Tibor Digaňa  wrote:
>>
>> Yes JDK8 is supported till 2030 but it looks like undefined in the table
>> below.
>> I don't consider this as a healthy argument that we should be on Java 8 as
>> well especially if it is the year 2030 because then we are affected by this
>> decision for years. The Maven 4 goes with Java 17 - I am glad. See this
>> table:
>> https://www.oracle.com/java/technologies/java-se-support-roadmap.html
>
>One more time: please don't confuse the Oracle Java support map with
>Java support. They are not the same thing. Java has had multiple
>vendors for almost 20 years. What Oracle will support is only what
>Oracle will support. I wouldn't even consider Oracle the primary
>vendor of Java any more.  IBM, Azul, Amazon, Microsoft, Red Hat, the
>OpenJDK Project, and others have significantly different schedules.
>
>A quick search does show Azul and Amazon ending support for Java 8 on
>January 1 2031 so 2030 is probably about the right time for us to
>consider dropping Java 8 support. I wouldn't do it before then. There
>are practical advantages to sticking on Java 8 that still outweigh the
>advantages of upgrading for some shops.
>

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Let's move Surefire project to JAVA 9. Surefire and Failsafe stop working on latest versions of Windows due to missing wmic.

[Hans Aikema]

> Op 11 feb 2026 om 16:27 heeft Thorsten Heit  het volgende 
> geschreven:
> 
> Hi,
> 
>> One more time: please don't confuse the Oracle Java support map with
>> Java support. They are not the same thing. Java has had multiple
>> vendors for almost 20 years. What Oracle will support is only what
>> Oracle will support. I wouldn't even consider Oracle the primary
>> vendor of Java any more.  IBM, Azul, Amazon, Microsoft, Red Hat, the
>> OpenJDK Project, and others have significantly different schedules.
>> A quick search does show Azul and Amazon ending support for Java 8 on
>> January 1 2031 so 2030 is probably about the right time for us to
>> consider dropping Java 8 support.

Waiting until the last commercial support vendor stops their (typically 
expensive) extended support offering of Java 8 would in my opinion not be the 
right approach.

>> I wouldn't do it before then. There
>> are practical advantages to sticking on Java 8 that still outweigh the
>> advantages of upgrading for some shops.
> 
> Correct, but personally I can't imagine having a good reason to still 
> restrict your codebase on Java 8 at the end of 2030, more than 16 years after 
> that version was released, when
> * there's Java 35 available (if I counted correctly and they're still using a 
> 6-month release cycle)
> * lots of LTS versions got released in the meantime until then (actually we 
> got four: 11, 17, 21 and 25).
> 

With the de facto frameworks of the Java enterprise eco-system (Spring 
Framework and Jakarta EE) having moved the low watermark of Java SE versions 
supported beyond 8 (Jakarta EE 10 to Java 11+, Spring 6/Jakarta EE 11 to Java 
17+) I'd say it would be a fine time to also put Java 8 support in Surefire to 
an end (or into a dormant critical security-fixes only mode) and raise the bar 
for current Surefire releases to newer Java SE releases.

All java releases up to now are still able to produce Java 8 bytecode if 
companies don't want to switch their production runtime - they just need to 
ensure that their codebase is not violating the implicit boundaries of the JVM 
internals that have since been shielded off to enable Surefire to run tests on 
Java 11 or later.

Keeping Java 11 support in surefire would be nice as that would help in getting 
bad Java 8 code (crossing the informal boundaries of the JVM internals) 
upgraded incrementally from one LTS to the other (benefitting from the 
typically 1 LTS version only JVM flags that on an opt-in basis re-allow the 
boundary crossing) until all usages of now shielded off internals are removed 
from an application and it can nicely run on the latest LTS release.



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Let's move Surefire project to JAVA 9. Surefire and Failsafe stop working on latest versions of Windows due to missing wmic.

[Thorsten Heit]

Hi,


One more time: please don't confuse the Oracle Java support map with
Java support. They are not the same thing. Java has had multiple
vendors for almost 20 years. What Oracle will support is only what
Oracle will support. I wouldn't even consider Oracle the primary
vendor of Java any more.  IBM, Azul, Amazon, Microsoft, Red Hat, the
OpenJDK Project, and others have significantly different schedules.

A quick search does show Azul and Amazon ending support for Java 8 on
January 1 2031 so 2030 is probably about the right time for us to
consider dropping Java 8 support. I wouldn't do it before then. There
are practical advantages to sticking on Java 8 that still outweigh the
advantages of upgrading for some shops.


Correct, but personally I can't imagine having a good reason to still 
restrict your codebase on Java 8 at the end of 2030, more than 16 years 
after that version was released, when
* there's Java 35 available (if I counted correctly and they're still 
using a 6-month release cycle)
* lots of LTS versions got released in the meantime until then (actually 
we got four: 11, 17, 21 and 25).




Thorsten


OpenPGP_0x5A54BBB878225E08.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Let's move Surefire project to JAVA 9. Surefire and Failsafe stop working on latest versions of Windows due to missing wmic.

[Thorsten Heit]

Hi,


Yes JDK8 is supported till 2030 but it looks like undefined in the table
below.
I don't consider this as a healthy argument that we should be on Java 8 as
well especially if it is the year 2030 because then we are affected by this
decision for years. The Maven 4 goes with Java 17 - I am glad. See this
table:
https://www.oracle.com/java/technologies/java-se-support-roadmap.html

If somebody understands this problem and especially the Surefire project
then he must realize that we are talking only about *Forked-JVM problem*. a
not the *In-Process* (means in-maven JVM execution). That's a big
difference because then we can split the decision in two:

*1. Maven plugin itself on Java 8 including the In-Process Provider, and*
*2. Forked-JVM on Java 9. This is not in contrast with the decision that
all Maven 3.x and plugins are on Java 8.*

Additionally, in practice you have the projects compiled by Java 8 compiler
but the runtime is at higher version and the reason is JVM performance. If
this is still not such case in some projects, then we should keep the code
as it is because it has polymorphism and the implementation was designed to
be extensible. This means that we can stick to the *WMIC* command and
switch to *ProcessHandle.isAlive() *if Java 9+ presents or if the *WMIC* is
not found, and this is I think a good compromise for everyone.

WDYT?


If you think about a new release, why not upgrading the corresponding 
codebase to at least Java 17 (better: 21) to stay in sync with the 
upcoming Maven 4?
This won't prevent users from still coding against Java 8, but can make 
the project's life much easier.



Just my 2ct

Thorsten


OpenPGP_0x5A54BBB878225E08.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Let's move Surefire project to JAVA 9. Surefire and Failsafe stop working on latest versions of Windows due to missing wmic.

[Romain Manni-Bucau]

do we have any advantage to stick on java 8 being said it doesnt prevent
users to run to move to java 26 today - they just dont upgrade as they do
for their java version?
it has more cons to stick on java 8, just the matri compat (vendors x
versions) can justify to keep only 2 lts IMHO.

Romain Manni-Bucau
@rmannibucau  | .NET Blog
 | Blog  | Old
Blog  | Github
 | LinkedIn
 | Book

Javaccino founder (Java/.NET service - contact via linkedin)


Le mer. 11 févr. 2026 à 15:28, Elliotte Rusty Harold  a
écrit :

> On Wed, Feb 11, 2026 at 2:09 PM Tibor Digaňa 
> wrote:
> >
> > Yes JDK8 is supported till 2030 but it looks like undefined in the table
> > below.
> > I don't consider this as a healthy argument that we should be on Java 8
> as
> > well especially if it is the year 2030 because then we are affected by
> this
> > decision for years. The Maven 4 goes with Java 17 - I am glad. See this
> > table:
> > https://www.oracle.com/java/technologies/java-se-support-roadmap.html
>
> One more time: please don't confuse the Oracle Java support map with
> Java support. They are not the same thing. Java has had multiple
> vendors for almost 20 years. What Oracle will support is only what
> Oracle will support. I wouldn't even consider Oracle the primary
> vendor of Java any more.  IBM, Azul, Amazon, Microsoft, Red Hat, the
> OpenJDK Project, and others have significantly different schedules.
>
> A quick search does show Azul and Amazon ending support for Java 8 on
> January 1 2031 so 2030 is probably about the right time for us to
> consider dropping Java 8 support. I wouldn't do it before then. There
> are practical advantages to sticking on Java 8 that still outweigh the
> advantages of upgrading for some shops.
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Let's move Surefire project to JAVA 9. Surefire and Failsafe stop working on latest versions of Windows due to missing wmic.

[Elliotte Rusty Harold]

On Wed, Feb 11, 2026 at 2:09 PM Tibor Digaňa  wrote:
>
> Yes JDK8 is supported till 2030 but it looks like undefined in the table
> below.
> I don't consider this as a healthy argument that we should be on Java 8 as
> well especially if it is the year 2030 because then we are affected by this
> decision for years. The Maven 4 goes with Java 17 - I am glad. See this
> table:
> https://www.oracle.com/java/technologies/java-se-support-roadmap.html

One more time: please don't confuse the Oracle Java support map with
Java support. They are not the same thing. Java has had multiple
vendors for almost 20 years. What Oracle will support is only what
Oracle will support. I wouldn't even consider Oracle the primary
vendor of Java any more.  IBM, Azul, Amazon, Microsoft, Red Hat, the
OpenJDK Project, and others have significantly different schedules.

A quick search does show Azul and Amazon ending support for Java 8 on
January 1 2031 so 2030 is probably about the right time for us to
consider dropping Java 8 support. I wouldn't do it before then. There
are practical advantages to sticking on Java 8 that still outweigh the
advantages of upgrading for some shops.

-- 
Elliotte Rusty Harold
elh...@ibiblio.org

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Let's move Surefire project to JAVA 9. Surefire and Failsafe stop working on latest versions of Windows due to missing wmic.

[Tibor Digaňa]

Yes JDK8 is supported till 2030 but it looks like undefined in the table
below.
I don't consider this as a healthy argument that we should be on Java 8 as
well especially if it is the year 2030 because then we are affected by this
decision for years. The Maven 4 goes with Java 17 - I am glad. See this
table:
https://www.oracle.com/java/technologies/java-se-support-roadmap.html

If somebody understands this problem and especially the Surefire project
then he must realize that we are talking only about *Forked-JVM problem*. a
not the *In-Process* (means in-maven JVM execution). That's a big
difference because then we can split the decision in two:

*1. Maven plugin itself on Java 8 including the In-Process Provider, and*
*2. Forked-JVM on Java 9. This is not in contrast with the decision that
all Maven 3.x and plugins are on Java 8.*

Additionally, in practice you have the projects compiled by Java 8 compiler
but the runtime is at higher version and the reason is JVM performance. If
this is still not such case in some projects, then we should keep the code
as it is because it has polymorphism and the implementation was designed to
be extensible. This means that we can stick to the *WMIC* command and
switch to *ProcessHandle.isAlive() *if Java 9+ presents or if the *WMIC* is
not found, and this is I think a good compromise for everyone.

WDYT?

You know, I don't like if somebody is proactively coding something but he
has no notion about the situation. This would lead to big stability issues
and we already have in new Maven version development problem which has a
common denominator and it is the organization problem, how we are organized
together. Therefore I was offline for some time and it was difficult for me
to join the team, and now it is too much, and now it is time to clarify the
things and make some order because we have to work together somehow with
some Timing Agreement and Plan...

Cheers
Tibor


On Sat, Feb 7, 2026 at 4:07 AM Greg Chabala  wrote:

> I don't relish having to say this, but JDK8 is still a supported platform
> by Oracle and others, and Surefire/Failsafe are very core plugins to Maven
> builds.
>
> Breaking JDK8 compatibility for future versions of the plugin 'because
> windows' seems premature.
>

Re: Let's move Surefire project to JAVA 9. Surefire and Failsafe stop working on latest versions of Windows due to missing wmic.

[Rob Spoor]

I wouldn't switch to Java 9. It's a non-LTS version and nobody should be 
using it anymore. I'd switch to Java 11 instead. I've recently done that 
for all of my own Java 8 projects as well. Even though Java 8 is still 
supported the major frameworks all support Java 11, and some even 
started requiring Java 17 (Spring, Quarkus).


Disclaimer: I am not a Maven developer, just a Maven user. Don't upgrade 
just because I said so ;)



On 07/02/2026 01:21, Tibor Digaňa wrote:

Hi all,

I would like to have your opinion regarding this issue reported on GitHub:
"Surefire and Failsafe stop working on latest versions of Windows due to
missing wmic"
Please see the link here
https://github.com/apache/maven-surefire/issues/3176

I am the author who developed the PPID Process Checker. When I worked on it
together with Michael Osipov, we reached a consensus. It was a very nice
personal collaboration, and now I would be glad to have this guy back in
the active Maven Team again :-)
That time we used Java 7 or Java 8, or even both, however Java 9 was
available in the world. We could not use the Java 9 however it could really
help us. Therefore we decided to call the system library "wmic" on Windows,
and "ps" on *Nix world, and not Java 9.

Due to the Microsoft Windows removed "wmic", I am open to move complete
Surefire project under Java 9.

I remember how problematic life it was when we had to support both Java 7
and Java 8 at the same time. I do not want to support two Java versions
again.
It would be easier for us to get a confidence from the Maven community and
switch to Java 9 directly.
I hope we would get an exception in the list of Maven plugins.

BTW, One more remark. There are strengths to destroy this project. Let's
ignore these strengths. We can prevent from this happening if we are
positive and we are friendly working together.


Cheers
Tibor17




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Let's move Surefire project to JAVA 9. Surefire and Failsafe stop working on latest versions of Windows due to missing wmic.

[Gary Gregory]

On Fri, Feb 6, 2026 at 10:07 PM Greg Chabala  wrote:
>
> I don't relish having to say this, but JDK8 is still a supported platform
> by Oracle and others, and Surefire/Failsafe are very core plugins to Maven
> builds.
>
> Breaking JDK8 compatibility for future versions of the plugin 'because
> windows' seems premature.

The Java req for building is different from the targeted version. You
can build on Java 25 for Java 8 for example.

Gary

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Let's move Surefire project to JAVA 9. Surefire and Failsafe stop working on latest versions of Windows due to missing wmic.

[Greg Chabala]

I don't relish having to say this, but JDK8 is still a supported platform
by Oracle and others, and Surefire/Failsafe are very core plugins to Maven
builds.

Breaking JDK8 compatibility for future versions of the plugin 'because
windows' seems premature.

Re: Let's move Surefire project to JAVA 9. Surefire and Failsafe stop working on latest versions of Windows due to missing wmic.

[Gary Gregory]

FWIW, it would make more sense to switch to an LTS version, the
closest being 11.

Gary

On Fri, Feb 6, 2026 at 7:22 PM Tibor Digaňa  wrote:
>
> Hi all,
>
> I would like to have your opinion regarding this issue reported on GitHub:
> "Surefire and Failsafe stop working on latest versions of Windows due to
> missing wmic"
> Please see the link here
> https://github.com/apache/maven-surefire/issues/3176
>
> I am the author who developed the PPID Process Checker. When I worked on it
> together with Michael Osipov, we reached a consensus. It was a very nice
> personal collaboration, and now I would be glad to have this guy back in
> the active Maven Team again :-)
> That time we used Java 7 or Java 8, or even both, however Java 9 was
> available in the world. We could not use the Java 9 however it could really
> help us. Therefore we decided to call the system library "wmic" on Windows,
> and "ps" on *Nix world, and not Java 9.
>
> Due to the Microsoft Windows removed "wmic", I am open to move complete
> Surefire project under Java 9.
>
> I remember how problematic life it was when we had to support both Java 7
> and Java 8 at the same time. I do not want to support two Java versions
> again.
> It would be easier for us to get a confidence from the Maven community and
> switch to Java 9 directly.
> I hope we would get an exception in the list of Maven plugins.
>
> BTW, One more remark. There are strengths to destroy this project. Let's
> ignore these strengths. We can prevent from this happening if we are
> positive and we are friendly working together.
>
>
> Cheers
> Tibor17

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org