mvnw.cmd crashes with "Cannot index into a null array" on 32-bit System Profile path (Jenkins service)

[naotsugu]

Affected version

3.3.3

Bug description

Description

In mvnw.cmd, the logic introduced by PR #143 to handle symlinks attempts to access an array index on the Target property without checking if it is null.

mvnw.cmd fails immediately upon execution with a "Cannot index into a null array" error. This issue specifically occurs when the script runs under the Local System account in a 32-bit process (typical for Jenkins Agents running as a Windows Service), where the default .m2 home resolves to the System Profile directory.

Error Log

icm : Cannot index into a null array
At line:1 char:81
+ ... 'mvnw.cmd'; icm -ScriptBlock ([Scriptblock]::Create((Get-Content -Raw ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [Invoke-Command], RuntimeException
    + FullyQualifiedErrorId : NullArray,Microsoft.PowerShell.Commands.InvokeCommandCommand

Environment

• OS: Windows Server 2022
• Process Architecture: 32-bit (x86)
• User: NT AUTHORITY\SYSTEM
• Target Path: C:\WINDOWS\system32\config\systemprofile\.m2
• PowerShell: 5.1

Root Cause Analysis

The script contains the following logic to handle symlinks:

if ((Get-Item $MAVEN_M2_PATH).Target[0] -eq $null) { ... }

We verified the behavior of the Target property on this specific environment:

1. Standard Paths (e.g., Workspace drive): The Target property returns an empty collection. Accessing [0] returns $null safely (in PowerShell 5.1).
2. System Profile Path (.m2): When accessing the .m2 directory in the System Profile from a 32-bit process, the Target property returns strictly $null.

Since mvnw.cmd defaults MAVEN_M2_PATH to the user home (System Profile), the script attempts to access index [0] on $null, causing a fatal RuntimeException.

Verification Code & Result

We ran the following diagnostic inside the failing Jenkins environment, specifically targeting the .m2 directory:

$basePath = $env:USERPROFILE
$m2Path = Join-Path $basePath ".m2"

# Ensure .m2 exists for testing
if (-not (Test-Path -Path $m2Path)) { New-Item -Path $m2Path -ItemType Directory | Out-Null }

$prop = (Get-Item $m2Path).Target

Write-Host "Testing Path: $m2Path"
Write-Host "Is Null? : " ($prop -eq $null)
try { $null = $prop[0]; Write-Host "Safe" } catch { Write-Host "CRASH" }

Output:

Testing Path: C:\WINDOWS\system32\config\systemprofile\.m2
Is Null? : True
CRASH

Proposed Fix

The script must check if the Target property is not null before attempting to index it.

Suggested Change:

$m2Item = Get-Item $MAVEN_M2_PATH

# Safe check: Ensure property exists and is not null before indexing
if ($m2Item.PSObject.Properties['Target'] -ne $null -and $m2Item.Target -ne $null) {
    $MAVEN_WRAPPER_DISTS = $m2Item.Target + "/wrapper/dists"
} else {
    $MAVEN_WRAPPER_DISTS = "$MAVEN_M2_PATH/wrapper/dists"
}

[fp024]

Hi,

Thank you for reporting this issue.

I wasn't able to test with a direct Jenkins installation on Windows, but I reproduced the problem by writing a test script that resolves the real path of the .m2 folder under the system profile in an x86 PowerShell process.

• https://github.com/fp024/win-file-link-test/blob/main/README_en.md

I also applied the fix from the PR to one of my local projects as a reference for how the change looks in practice:

• fp024/spring-mvc-practice-study@16f96fa

The fix in the PR should address the issue — could you please verify on your end? Thank you 👍

[naotsugu]

The modifications were reflected in mvnw.cmd in the Jenkins workspace, and I confirmed that the previously reported error has been resolved.
This issue is now considered resolved.
Thank you ☺️

---

However, although the script error was fixed, I encountered a "Could not find or load main class org.codehaus.plexus.classworlds.launcher.Launcher" error, and the build could not be completed.

The environment is Windows Server 2022 Datacenter 21H2, and environment variables such as M2_HOME, M2, and MAVEN_USER_HOME are not set.

The command executed from mvnw.cmd is as follows:

C:\WINDOWS\system32\config\systemprofile\.m2\wrapper\dists\apache-maven-3.9.11\03d7e36a140982eea48e22c1dcac01d8862b2550b2939e09a0809bbc5182a5bc\bin\mvn.cmd

When I execute the following in the Jenkins "Execute Windows batch command" step, I get the "Could not find or load main class org.codehaus.plexus.classworlds.launcher.Launcher" error:

mvnw clean package

If I set MAVEN_USER_HOME as follows, the build succeeds:

set MAVEN_USER_HOME=%WORKSPACE%\.m2
mvnw clean package

There might be some restrictions on the systemprofile system folder, or the path to mvn.cmd might be too long.
I have not investigated the detailed cause.

[fp024]

Hi,

Thank you for the confirmation.

I previously mentioned in the document linked in the PR that Jenkins might need to run on an x86 JDK when an x86 build is required in an x64 environment. However, as you suggested, setting MAVEN_USER_HOME manually seems like a much better approach:

set MAVEN_USER_HOME=%WORKSPACE%\.m2
mvnw clean package

While setting MAVEN_USER_HOME to the workspace is a straightforward solution, it does result in each Jenkins x86 job having its own .m2 folder. To reduce this redundancy, another option worth considering is defining a dedicated, independent path for x86 Maven on the Windows server.

I believe the root cause of the issue is as follows:

When Jenkins itself runs on an x64 JDK, the PowerShell code within mvnw.cmd runs as a 64-bit process, creating the wrapper under the System32 path (C:\Windows\System32\config\systemprofile\.m2\wrapper). However, if the build then uses an x86 JDK, the wrapper attempts to find the required JAR libraries in C:\Windows\SysWOW64\config\systemprofile\.m2\wrapper, leading to a ClassNotFoundException due to Windows file system redirection.

Therefore, setting MAVEN_USER_HOME to a path independent of the system profile is a far more practical solution. My previous idea of running a separate Jenkins instance with an x86 JDK seems unnecessarily complicated in comparison. 😅

Thank you!

References

• https://github.com/fp024/win-file-link-test/tree/main/java-project

[fp024]

One more interesting finding:

Another definitive way to handle this in an x64 Jenkins environment is to explicitly invoke the 32-bit shell:

C:\Windows\SysWOW64\cmd.exe /c mvnw clean package