Enable ansi support by default on Windows 11+#49571
Enable ansi support by default on Windows 11+#49571snicoll merged 2 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. |
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 :) 
|
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.
There was a problem hiding this comment.
Ah okay now i get it :D
Will update the PR.
wilkinsona
added
status: waiting-for-feedback
|
Updated PR with the suggested changes |
spring-projects-issues
added
status: feedback-provided
snicoll
added
type: enhancement
snicoll
changed the title
snicoll
changed the title
See spring-projectsgh-49571 Signed-off-by: Philemon Hilscher <philemon847@gmail.com>
snicoll
force-pushed
the
implement-windows-ansi-support-detection
branch
from
ef7c648 to
11d1498
Compare
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. :)