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.

[Olivier Lamy]

Hi,
PR has been opened to restore the previously reverted commit:
https://github.com/apache/maven-surefire/pull/3263
After reviewing this more carefully, it appears that only a single
commit was reverted.
I initially misunderstood Tibor’s email, as it referred to replacing
WMIC with PowerShell; however, that change was not part of the revert.
As a result, there is only one commit to restore. Unless Tibor
indicates he would prefer to handle this himself, I plan to merge the
reapplication PR after a period of time (24h).

Regards
Olivier

On Mon, 16 Feb 2026 at 09:33, 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
> >  > 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 users in that situation, possible options include:
> > > - remaining on Surefire 3.5.4 (they are already using old Java 8 and
> > > old Windows version)
> > > - upgrading to at least Java 9
> > > - installing PowerShell
> > >
> > > I am also concerned about the process/community aspect. These PRs had
> > > received few community approvals, which indicated consensus to move
> > > forward.
> > > Reverting them without prior discussion on the mailing list or in the
> > > PR bypasses that consensus-building process.
> > > I would therefore suggest reverting those reverts as they are
> > > affecting changes that have already been approved.
> > > Regards
> > > Olivier
> > >
> > > On Sun, 15 Feb 2026 at 10:07, Tibor Digaňa  wrote:
> > > > 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.
> > >
> > > So there is nothing such a single person to validate changes.
> > > We are a developer community here. PRs are public and can be validated
> > > by any community member.
> > >
> > > > 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 tr

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

[Hervé Boutemy]

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
>  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 users in that situation, possible options include:
> > - remaining on Surefire 3.5.4 (they are already using old Java 8 and
> > old Windows version)
> > - upgrading to at least Java 9
> > - installing PowerShell
> > 
> > I am also concerned about the process/community aspect. These PRs had
> > received few community approvals, which indicated consensus to move
> > forward.
> > Reverting them without prior discussion on the mailing list or in the
> > PR bypasses that consensus-building process.
> > I would therefore suggest reverting those reverts as they are
> > affecting changes that have already been approved.
> > Regards
> > Olivier
> > 
> > On Sun, 15 Feb 2026 at 10:07, Tibor Digaňa  wrote:
> > > 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.
> > 
> > So there is nothing such a single person to validate changes.
> > We are a developer community here. PRs are public and can be validated
> > by any community member.
> > 
> > > 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
> > 
> 

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]

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

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 users in that situation, possible options include:
> - remaining on Surefire 3.5.4 (they are already using old Java 8 and
> old Windows version)
> - upgrading to at least Java 9
> - installing PowerShell
>
> I am also concerned about the process/community aspect. These PRs had
> received few community approvals, which indicated consensus to move
> forward.
> Reverting them without prior discussion on the mailing list or in the
> PR bypasses that consensus-building process.
> I would therefore suggest reverting those reverts as they are
> affecting changes that have already been approved.
> Regards
> Olivier
>
> On Sun, 15 Feb 2026 at 10:07, Tibor Digaňa  wrote:
> >
> > 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.
> >
>
> So there is nothing such a single person to validate changes.
> We are a developer community here. PRs are public and can be validated
> by any community member.
>
> > 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. Additional

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

[Olivier Lamy]

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 users in that situation, possible options include:
- remaining on Surefire 3.5.4 (they are already using old Java 8 and
old Windows version)
- upgrading to at least Java 9
- installing PowerShell

I am also concerned about the process/community aspect. These PRs had
received few community approvals, which indicated consensus to move
forward.
Reverting them without prior discussion on the mailing list or in the
PR bypasses that consensus-building process.
I would therefore suggest reverting those reverts as they are
affecting changes that have already been approved.
Regards
Olivier

On Sun, 15 Feb 2026 at 10:07, Tibor Digaňa  wrote:
>
> 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.
>

So there is nothing such a single person to validate changes.
We are a developer community here. PRs are public and can be validated
by any community member.

> 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

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.

[Olivier Lamy]

On Wed, 11 Feb 2026 at 23:32, Tibor Digaňa  wrote:
>
> We should hold on with Olivier Lamy's PR because I want to discuss Java 9
> feature.
> Has the *ProcessHandle* guaranteed services or they are optional due to
> this is strongly related to the operating systems?

Perhaps some home-made JDK built by an AI for marketing purposes does
not support this JEP. But can we seriously Keep It Stupid Simple (™)?
This JEP dates back to 2011: https://openjdk.org/jeps/102
If a JDK claiming to be Java 9 compatible does not implement it, then
that JDK likely has broader compatibility issues.
Just a reminder: Surefire is maintained as part of the Maven plugin
ecosystem. There shouldn’t be a discussion about “Surefire on Java 9+”
in isolation.
If anything, this should be a broader discussion covering plugins,
Maven core, and the overall ecosystem.
We’ve already discussed this extensively over the past few years and
reached a general consensus around a common versioning scheme:
3.x -> Maven Core API 3.x, JDK 8
4.x -> Maven Core API 4.x, JDK 17

If further discussion is needed, it should occur at a higher level to
ensure consistent, non-confusing versioning across the ecosystem.
Maybe we can change in the future, but there is no need to hold PRs
and stop moving forward. That's a bit counterproductive.

Personal opinion: rather than reopening the same debate, perhaps we
should focus on getting Maven 4.x out so that plugins can migrate
accordingly.


> Regarding the PowerShell, what guarantee you have that the user has
> PowerShell installed on the OS? Let's not think about the latest Windows.
>

so users just install it or do not upgrade surefire.

> T
>
> On Sun, Feb 8, 2026 at 12:50 AM Michael Osipov  wrote:
>
> > Thank you for the kind words...
> >
> > Why not use the equivalent in PowerShell? For me, it is totally fine until
> > the plugin moved to Maven 4...
> >
> > E.g.:
> >  Process process = new ProcessBuilder(
> > "powershell",
> > "-NoProfile",
> > "-Command",
> > "Get-CimInstance Win32_Process -Filter \"ProcessId=" +
> > pid +
> > "\" | Select-Object -Expand ParentProcessId")
> >
> > WDYT?
> >
> > On 2026/02/07 00:21:05 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: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.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.

[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: 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.

[Václav Haisman]

On 2/8/26 00:50, Michael Osipov wrote:

Thank you for the kind words...

Why not use the equivalent in PowerShell? For me, it is totally fine until the 
plugin moved to Maven 4...

E.g.:
  Process process = new ProcessBuilder(
 "powershell",
 "-NoProfile",
 "-Command",
 "Get-CimInstance Win32_Process -Filter \"ProcessId=" + pid 
+
 "\" | Select-Object -Expand ParentProcessId")

WDYT?


What about JNA and the CreateToolhelp32Snapshot function? https://java-native-access.github.io/jna/4.2.0/com/sun/jna/platform/win32/Kernel32.html#CreateToolhelp32Snapshot-com.sun.jna.platform.win32.WinDef.DWORD-com.sun.jna.platform.win32.WinDef.DWORD->


Or is there more to it than just finding the parent alive via PID?



On 2026/02/07 00:21:05 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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org




--
VH

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: 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.

[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.

[Tibor Digaňa]

We should hold on with Olivier Lamy's PR because I want to discuss Java 9
feature.
Has the *ProcessHandle* guaranteed services or they are optional due to
this is strongly related to the operating systems?
Regarding the PowerShell, what guarantee you have that the user has
PowerShell installed on the OS? Let's not think about the latest Windows.

T

On Sun, Feb 8, 2026 at 12:50 AM Michael Osipov  wrote:

> Thank you for the kind words...
>
> Why not use the equivalent in PowerShell? For me, it is totally fine until
> the plugin moved to Maven 4...
>
> E.g.:
>  Process process = new ProcessBuilder(
> "powershell",
> "-NoProfile",
> "-Command",
> "Get-CimInstance Win32_Process -Filter \"ProcessId=" +
> pid +
> "\" | Select-Object -Expand ParentProcessId")
>
> WDYT?
>
> On 2026/02/07 00:21:05 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: 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.

[Olivier Lamy]

Hi,
Yes, it looks to be implemented in this PR:
https://github.com/apache/maven-surefire/pull/3258?
Sorry, I'm not a Windows user, so I can not really have a strong opinion there.

On Sun, 8 Feb 2026 at 09:52, Michael Osipov  wrote:
>
> Thank you for the kind words...
>
> Why not use the equivalent in PowerShell? For me, it is totally fine until 
> the plugin moved to Maven 4...
>
> E.g.:
>  Process process = new ProcessBuilder(
> "powershell",
> "-NoProfile",
> "-Command",
> "Get-CimInstance Win32_Process -Filter \"ProcessId=" + 
> pid +
> "\" | Select-Object -Expand ParentProcessId")
>
> WDYT?
>
> On 2026/02/07 00:21:05 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: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.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.

[Michael Osipov]

Thank you for the kind words...

Why not use the equivalent in PowerShell? For me, it is totally fine until the 
plugin moved to Maven 4...

E.g.:
 Process process = new ProcessBuilder(
"powershell",
"-NoProfile",
"-Command",
"Get-CimInstance Win32_Process -Filter \"ProcessId=" + pid +
"\" | Select-Object -Expand ParentProcessId")

WDYT?

On 2026/02/07 00:21:05 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: 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.

[Yeikel Santana]

Hi,


What is the concern with building using the latest LTS version (25 as of today) 
while still targeting Java 8 using the release javac flag? 


What am I overlooking?


Thanks!





  On Sat, 07 Feb 2026 11:22:09 -0500  mbuen...@apache.org  wrote 

Hi,

as we all expect that it will take years that the majority of users will switch 
to Maven 4, we still have to support Maven 3 as surefire is one of the core 
plugins. Lifting the required Java version for a 3.x surefire (or any other 
plugin), therefore requires a lifting of the minimum Java version of Maven 3. 
So we need to find a fix or call Surefire 3.x EOL due to this. And as an 
information: Windows is used a lot in dev teams, esp in those companies with 
heaving policies.



Regarless of the rising ignorance of Windows users I agree on this statement:



>>

The idea I mentioned in another thread [2] is to keep aligning

Surefire with the model we already use for the rest of the codebase

(plugins, shared components, etc.):

- 3.x branch, versioned as 3.x, Core API 3.x (i.e. Java 8 support)

- master branch, versioned as 4.x, Core API 4.x (i.e. Java 17 support)



This is a pattern we’ve consistently adopted across all plugins. I

don’t really see why we should change it here.

>>



so a +1 (nb) to create a 4.x version and a 3.x release branch





Am 07.02.2026 um 05:29 schrieb Olivier Lamy:

> The idea I mentioned in another thread [2] is to keep aligning

> Surefire with the model we already use for the rest of the codebase

> (plugins, shared components, etc.):

> - 3.x branch, versioned as 3.x, Core API 3.x (i.e. Java 8 support)

> - master branch, versioned as 4.x, Core API 4.x (i.e. Java 17 support)

>

> This is a pattern we’ve consistently adopted across all plugins. I

> don’t really see why we should change it here.

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

[Matthias Bünger]

Hi,
as we all expect that it will take years that the majority of users will switch 
to Maven 4, we still have to support Maven 3 as surefire is one of the core 
plugins. Lifting the required Java version for a 3.x surefire (or any other 
plugin), therefore requires a lifting of the minimum Java version of Maven 3. 
So we need to find a fix or call Surefire 3.x EOL due to this. And as an 
information: Windows is used a lot in dev teams, esp in those companies with 
heaving policies.

Regarless of the rising ignorance of Windows users I agree on this statement:




The idea I mentioned in another thread [2] is to keep aligning
Surefire with the model we already use for the rest of the codebase
(plugins, shared components, etc.):
- 3.x branch, versioned as 3.x, Core API 3.x (i.e. Java 8 support)
- master branch, versioned as 4.x, Core API 4.x (i.e. Java 17 support)

This is a pattern we’ve consistently adopted across all plugins. I
don’t really see why we should change it here.




so a +1 (nb) to create a 4.x version and a 3.x release branch


Am 07.02.2026 um 05:29 schrieb Olivier Lamy:

The idea I mentioned in another thread [2] is to keep aligning
Surefire with the model we already use for the rest of the codebase
(plugins, shared components, etc.):
- 3.x branch, versioned as 3.x, Core API 3.x (i.e. Java 8 support)
- master branch, versioned as 4.x, Core API 4.x (i.e. Java 17 support)

This is a pattern we’ve consistently adopted across all plugins. I
don’t really see why we should change it here.

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]

+1 for the PR. It doesn't drop JDK8; support, really. We can still fix JDK8 on 
Win11 later if needed. Or users need to install this utility.

Let's make JDK9+ on latest windows work again, better than the status quo.

- Ben



On 7 February 2026 05:29:05 CET, Olivier Lamy  wrote:
>Let’s reduce the scope of this discussion to @dev only.
>
>I agree on the LTS point: Java 11 is getting old now and is only
>supported commercially [1]. Because of that, I’m not fully convinced
>that moving the minimum to 9 is really necessary either.
>The idea I mentioned in another thread [2] is to keep aligning
>Surefire with the model we already use for the rest of the codebase
>(plugins, shared components, etc.):
>- 3.x branch, versioned as 3.x, Core API 3.x (i.e. Java 8 support)
>- master branch, versioned as 4.x, Core API 4.x (i.e. Java 17 support)
>
>This is a pattern we’ve consistently adopted across all plugins. I
>don’t really see why we should change it here.
>Personally, I’d prefer that we focus our efforts on 4.x (core and all
>plugins), letting Java 17 naturally become the de facto standard for
>all plugins/shared etc...
>
>Regarding the proposed fix in 
>https://github.com/apache/maven-surefire/pull/3252
>It deprecates the old pidchecker (which we can’t realistically remove
>in 3.x anyway, so it can stay around a bit longer in 3.x.x branches
>while offering an alternative), and it also makes the Surefire plugin
>work on Windows without requiring the binary (e.g. on windows-latest
>in GitHub Actions).
>
>With this fix:
>The deprecated part can be fully removed in 4.x (which could start
>quite soon—see steps in [2]).
>The only remaining unsupported case would be Windows without the
>binary on Java 8 (some recent or server Windows version, sorry, I’m
>not a Windows user, so I can’t be more precise).
>This should affect a fairly limited number of users, and there are
>workarounds available:
>- Use an older Windows runner (e.g. windows-2022 on GHA). If they’re
>already on Java 8, using an older OS is probably acceptable 🙂
>- Use Java 9+
>- Install the missing binary (if that’s even possible, again not a
>Windows user so I have no much idea)
>
>Overall, I think we can keep this simple.
>The simplest path forward, in my view, would be:
>
>Release 3.5.5 as described in the proposal from [2] with this fix to
>help many users immediately.
>Then move ahead with the rest of the proposal.
>
>Regards,
>Olivier
>
>[1] Oracle JDK dates https://endoflife.date/oracle-jdk
>[2] https://lists.apache.org/thread/phy3g1dzvh0lkj7c3boxwz345180m8vy
>
>
>On Sat, 7 Feb 2026 at 11:26, Gary Gregory  wrote:
>>
>> 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
>>
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>For additional commands, e-mail: dev-h...@maven.apache.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.

[Olivier Lamy]

Let’s reduce the scope of this discussion to @dev only.

I agree on the LTS point: Java 11 is getting old now and is only
supported commercially [1]. Because of that, I’m not fully convinced
that moving the minimum to 9 is really necessary either.
The idea I mentioned in another thread [2] is to keep aligning
Surefire with the model we already use for the rest of the codebase
(plugins, shared components, etc.):
- 3.x branch, versioned as 3.x, Core API 3.x (i.e. Java 8 support)
- master branch, versioned as 4.x, Core API 4.x (i.e. Java 17 support)

This is a pattern we’ve consistently adopted across all plugins. I
don’t really see why we should change it here.
Personally, I’d prefer that we focus our efforts on 4.x (core and all
plugins), letting Java 17 naturally become the de facto standard for
all plugins/shared etc...

Regarding the proposed fix in https://github.com/apache/maven-surefire/pull/3252
It deprecates the old pidchecker (which we can’t realistically remove
in 3.x anyway, so it can stay around a bit longer in 3.x.x branches
while offering an alternative), and it also makes the Surefire plugin
work on Windows without requiring the binary (e.g. on windows-latest
in GitHub Actions).

With this fix:
The deprecated part can be fully removed in 4.x (which could start
quite soon—see steps in [2]).
The only remaining unsupported case would be Windows without the
binary on Java 8 (some recent or server Windows version, sorry, I’m
not a Windows user, so I can’t be more precise).
This should affect a fairly limited number of users, and there are
workarounds available:
- Use an older Windows runner (e.g. windows-2022 on GHA). If they’re
already on Java 8, using an older OS is probably acceptable 🙂
- Use Java 9+
- Install the missing binary (if that’s even possible, again not a
Windows user so I have no much idea)

Overall, I think we can keep this simple.
The simplest path forward, in my view, would be:

Release 3.5.5 as described in the proposal from [2] with this fix to
help many users immediately.
Then move ahead with the rest of the proposal.

Regards,
Olivier

[1] Oracle JDK dates https://endoflife.date/oracle-jdk
[2] https://lists.apache.org/thread/phy3g1dzvh0lkj7c3boxwz345180m8vy


On Sat, 7 Feb 2026 at 11:26, Gary Gregory  wrote:
>
> 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
>

-
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.

[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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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,

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