Change the ansi support detection to return true for Windows 10+#49571
Change the ansi support detection to return true for Windows 10+#49571plumstone wants to merge 3 commits intospring-projects:mainfrom
Conversation
spring-projects-issues
added
the
status: waiting-for-triage
plumstone
force-pushed
the
implement-windows-ansi-support-detection
branch
from
56d6be5 to
4e6a7d3
Compare
|
We've had a similar request in the past and found ANSI support in Windows quite hard to get working consistently. See #34835 (comment) for some previous analysis. If we do consider this again, I think it should be for Windows 11+ only. |
|
@plumstone would you like to update your proposed changes so that they're Windows 11+ only? |
wilkinsona
added
the
status: waiting-for-feedback
|
@plumstone how is it going? No rush but wondering if that's still on your radar as we're approaching RC1. |
Signed-off-by: Philemon Hilscher <philemon847@gmail.com>
plumstone
force-pushed
the
implement-windows-ansi-support-detection
branch
from
4e6a7d3 to
41585ec
Compare
|
Implementation is done. I just tested the changes in a built bootJar. Works fine :) 
|
Signed-off-by: Philemon Hilscher <philemon847@gmail.com>
plumstone
force-pushed
the
implement-windows-ansi-support-detection
branch
from
41585ec to
3b1349d
Compare
spring-projects-issues
added
status: feedback-provided
| Process buildNumberRequest = Runtime.getRuntime().exec( | ||
| "reg query \"HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\" /v " + CURRENT_BUILD); | ||
| return new String(buildNumberRequest.getInputStream().readAllBytes()); |
There was a problem hiding this comment.
I think shelling out like this might be a deal-breaker for me. Is there really no other way to detect Windows 11?
There was a problem hiding this comment.
Looking at https://bugs.openjdk.org/browse/JDK-8274840, I think we could use the os.name system property looking for a value of Windows 11 instead.
There was a problem hiding this comment.
I can change it to os.name detection. But I don't know how long that will work reliably.
There was a problem hiding this comment.
Yes please.
Given how it's implemented it should be no less reliable than what's proposed here.
There was a problem hiding this comment.
Updated the branch. It was a bit trickier than I thought because the os name is quite different for windows server instances. But I added more tests which should cover all corner cases.
There was a problem hiding this comment.
Thanks for the updates. Unfortunately, that's not quite what I had in mind. I think we should just look for the string Windows 11 without any parsing. We could also look for Windows Server 2025 which was added in Java 24. If the JDK team add more possible values to os.name, Boot can be updated to match at that time. I think that's preferable to the proposed parsing that adds quite a bit of complexity for no current benefit.
wilkinsona
added
status: waiting-for-feedback
…name" Signed-off-by: Philemon Hilscher <philemon847@gmail.com>
5 participants
Enhancement proposal
Windows supports console ANSI output since build 10586 (End of 2015). Therefore I thought it would make sense to update the ANSI support detection in Spring Boot.
The only slight issue I noticed is that the JDK does not return the build number for Windows systems which in result cannot be checked. https://github.com/openjdk/jdk/blob/master/src/java.base/windows/native/libjava/java_props_md.c#L502
So with this change only the earliest versions of Windows 10 until 2016 (which are no longer supported anyway) would give out a wrong result whether they support ANSI.
Now I need your feedback. Is this acceptable? Should I add more test cases?
Thanks in advance. :)