[Bug] Failed to start under Windows with JDK17

[cyb1103]

Before Creating the Bug Report

• I found a bug, not just asking a question, which should be created in GitHub Discussions.

• I have searched the GitHub Issues and GitHub Discussions of this repository and believe that this is not a duplicate.

• I have confirmed that this bug belongs to the current repository, not other repositories of RocketMQ.

Runtime platform environment

Windows 11

RocketMQ version

rocketmq-all-5.2.0-bin-release

JDK Version

Oracle JDK 1.8.0_181
Oracle Oracle 17.0.6

Describe the Bug

当我在windows11，JDK17环境下 启动mqnanesrv.cmd时报错“此时不应有 ***\lib\dt.jar”，我在lssues中搜索windows启动失败相关的案例7495，我检查了我的版本是包含这一部分代码的，经过长时间的排查是我本地历史为dt.jar和tools.jar配置了环境变量导致启动异常,在排查过程中发现了一个问题。
在下面脚本中
for /f "tokens=2 delims=" %%v in ('java -version 2^>^&1 ^| findstr /i "version"') do ( for /f "tokens=1 delims=." %%m in ("%%v") do set "JAVA_MAJOR_VERSION=%%m" )
第一步未指定分割符导致返回值一直为空白

最终赋值为0
if "%JAVA_MAJOR_VERSION%"=="" ( set "JAVA_MAJOR_VERSION=0" )
永远走的小于17的分支

I translated it using AI
The information you sent earlier, translated into English, is as follows:

When I try to start mqnamesrv.cmd in a Windows 11 environment with JDK 17, I encounter an error message stating "Unexpected ***\lib\dt.jar at this time". I searched for related issues regarding startup failures on Windows in issue 7495 on GitHub. I checked and confirmed that my version does include the relevant code. After a lengthy troubleshooting process, I discovered that the issue was caused by my local environment variables that were historically configured for dt.jar and tools.jar, which were causing the startup to fail.

for /f "tokens=2 delims=" %%v in ('java -version 2^>^&1 ^| findstr /i "version"') do (
    for /f "tokens=1 delims=." %%m in ("%%v") do set "JAVA_MAJOR_VERSION=%%m"
)

The first for loop does not specify a delimiter that would properly parse the output of java -version, resulting in the variable %%v always being empty.

As a result, JAVA_MAJOR_VERSION is always assigned the value 0.

if "%JAVA_MAJOR_VERSION%"=="" (
    set "JAVA_MAJOR_VERSION=0"
)

This means that the script always falls into the branch for Java versions less than 17.

The issue lies in the fact that the output of java -version on Windows is formatted differently than what the script expects, and the delims= in the first for loop does not effectively split the string as intended. The script needs to be adjusted to correctly parse the version number from the java -version output.

Steps to Reproduce

1.下载rocketMq
2.运行 mqnamesrv.cmd

What Did You Expect to See?

运行参数为jdk17 的运行参数

What Did You See Instead?

实际为小于17分支使用的参数

Additional Context

No response

[acearth]

jdk21、jdk17下都不能正常工作，环境macOS m1、m2。 rocketMQ真的有人在认真做开发吗 ？

还在用老掉牙、已经淘汰的偏向锁技术，jdk17都上不了。

[cyb1103]

jdk21、jdk17下都不能正常工作，环境macOS m1、m2。 rocketMQ真的有人在认真做开发吗 ？

还在用老掉牙、已经淘汰的偏向锁技术，jdk17都上不了。

应该不至于，windows上启动的人确实少、启动脚本这一块就很简陋，我看linux的启动脚本挺完善的，虽然我没启动过

[acearth]

jdk21、jdk17下都不能正常工作，环境macOS m1、m2。 rocketMQ真的有人在认真做开发吗 ？
还在用老掉牙、已经淘汰的偏向锁技术，jdk17都上不了。

应该不至于，windows上启动的人确实少、启动脚本这一块就很简陋，我看linux的启动脚本挺完善的，虽然我没启动过

为什么应该不至于？ 没看到文档虽然说最小要求jdk1.8， 但实际示例也都是jdk1.8吗？ 偏向锁报错这个问题，运行一次就能看到。

Talk is cheap。

[hassan5134]

I encountered a similar issue. When I tried to restart the broker, it failed to start.
Environment：JDK17

2025-02-11 16:10:47 INFO main - Try to start service thread:AllocateMappedFileService started:false lastThread:null
2025-02-11 16:10:47 INFO main - Try to shutdown service thread:AllocateMappedFileService started:true lastThread:Thread[AllocateMappedFileService,5,main]
2025-02-11 16:10:47 INFO main - shutdown thread AllocateMappedFileService interrupt true
2025-02-11 16:10:47 INFO main - join thread AllocateMappedFileService elapsed time(ms) 0 90000
2025-02-11 16:10:47 INFO main - Try to shutdown service thread:PullRequestHoldService started:false lastThread:null

Downgrading to JDK 8 resolved the issue.