[Bug] Failed to start under Windows with JDK17

cyb1103 commented 1 month ago

Before Creating the Bug Report

[X] I found a bug, not just asking a question, which should be created in GitHub Discussions.
[X] I have searched the GitHub Issues and GitHub Discussions of this repository and believe that this is not a duplicate.
[X] 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 commented 1 month ago

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

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

cyb1103 commented 1 month ago

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

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

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

acearth commented 1 month ago

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

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

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

Talk is cheap。

apache / rocketmq