adoptium
Regression "no screen devices" in Windows Containers
Please provide a brief summary of the bug
Hello I am running a java application in windows containers. When updating from 21.0.3+9 LTS to 21.0.5+11-LTS I started getting the an error when running my application in a windows container. There is no other change in how the application was executed besides swapping out the JDK.
This happend on multiple different hardware machines and is 100% Reproducable on my end. For some reason java appears to no longer be able to detect the number of screens (which should be 1) inside a windows container. sun.awt.Win32GraphicsEnvironment#getNumScreens appears to return 0 after the update.
While there is no way to see this screen, you can take screenshots from this virtual screen so it is there and I think java should be able to use it, and as mentioned it did work in older versions of java 21 as well as previous versions of java (11 and 17).
Any help with this would be much appreciated!
Did you test with the latest update version?
- [x] Yes
Please provide steps to reproduce where possible
Execute any java code that calls sun.awt.Win32GraphicsEnvironment#getNumScreens inside a windows container based on mcr.microsoft.com/windows/server:ltsc2022
The call I made was getFontMetrics on a JSpinner, but I belive it is irrelevant which JComponent you use.
Expected Results
sun.awt.Win32GraphicsEnvironment#getNumScreens returns 1 in a windows container
Actual Results
java.lang.ExceptionInInitializerError: Exception java.awt.AWTError: no screen devices [in thread "Test worker"]
at java.desktop/sun.awt.Win32GraphicsEnvironment.getDefaultScreenDevice(Win32GraphicsEnvironment.java:101)
at java.desktop/sun.font.FontDesignMetrics.getDefaultFrc(FontDesignMetrics.java:157)
at java.desktop/sun.font.FontDesignMetrics.getMetrics(FontDesignMetrics.java:274)
at java.desktop/sun.swing.SwingUtilities2.getFontMetrics(SwingUtilities2.java:1242)
at java.desktop/javax.swing.JComponent.getFontMetrics(JComponent.java:1700)
...
What Java Version are you using?
openjdk 21.0.5 2024-10-15 LTS OpenJDK Runtime Environment Temurin-21.0.5+11 (build 21.0.5+11-LTS) OpenJDK 64-Bit Server VM Temurin-21.0.5+11 (build 21.0.5+11-LTS, mixed mode, sharing)
What is your operating system and platform?
Windows Server 2022
How did you install Java?
The windows containers image is based on mcr.microsoft.com/windows/server:ltsc2022 Other than changing the JDK I did not modify any other aspect of the container. The JDK zip is "unpacked" using the appropriate powershell command when building the image for the container. I am not using any of adoptiums docker containers due to other reasons that are not relevant for this bug.
Did it work before?
The following versions worked and did not throw an exception
Adoptium 21.0.2+13
Adoptium 21.0.3+9
The following versions did NOT work and threw the mentioned exception:
Adoptium 21.0.5+11
Adoptium 21.0.4+7
Did you test with other Java versions?
Old java 17 which also works:
openjdk 17.0.9 2023-10-17
OpenJDK Runtime Environment Temurin-17.0.9+9 (build 17.0.9+9)
OpenJDK 64-Bit Server VM Temurin-17.0.9+9 (build 17.0.9+9, mixed mode, sharing)
Relevant log output
@AlexanderSchuetz97 Are you able to try with 21.0.6 next week when it comes out and report back here?
This looks to be a similar issue to https://bugs.openjdk.org/browse/JDK-8336862 caused by https://bugs.openjdk.org/browse/JDK-8185862 new in 21.0.4. See also https://github.com/adoptium/adoptium-support/issues/1203
@karianna It is trivial for me to try with different versions of java. I only have to swap out the zip file with the setup. I will do so once it releases. @jerboaa I belive https://bugs.openjdk.org/browse/JDK-8336862 is indeed my issue. It is pretty similar situation (windows container vs windows service on windows server)
Something I forgot to mention is that I also tried "-Djava.awt.headless=false" to no effect.
This is effectively the same exact issue as #1203. Same exact cause. Same broken DLL.
Lack of physical hardware screens supposedly means you don't have a GPU or other canvas to paint to anymore? Is that the logic?
The Java Win UI backend code appears to be going to great lengths to report physical screens only. And appears to reprobe them a lot while doing UI ops. I don't want to know about the performance issues that might cause as well.
I'm not in a position to test it, but what happens if you physically unplug all monitors?
Thanks for your info!
Ive read through that issue aswell as other related issues linked. It has really only achieved in making me more angry. Not at any individual in particular just in general... How was this blunder allowed to happen?
We also have swing apps that are used over RDP. The apps crashing when the rdp session is paused is a deal breaker for us. I didnt even get to test that part yet...
And besides windows containers we also use windows services for the same app (We allow customer to pick which way they want to install our software) so we would have ran into your exact issue too...
If this isnt fixed (which I doubt by this point since this issue has persisted for apparently 6 months without beeing addressed) then I guess we will be forced to compile our own JDK in the short term with this bug patched out and in the long term move away from the java platform.
As per recommendation in your issue I will be trying the jetbrains runtime, but its unsuitable for production as they dont backport security fixes long enough to be compatible with the release and support cycles of our software...
@karianna You mentioned that 21.0.6 may fix the issue, but I dont see any commits in the openjdk repo that would suggest this? Am I just blind or is adoptium taking the same approch as jetbrains and just reverts the bug on their end? If so that would be EPIC!
Thanks to all involved for their effort, I would have wasted countless hours looking for a problem on our end otherwise.
@karianna It is trivial for me to try with different versions of java. I only have to swap out the zip file with the setup. I will do so once it releases. @jerboaa I believe https://bugs.openjdk.org/browse/JDK-8336862 is indeed my issue. It is pretty similar situation (windows container vs windows service on windows server)
Any update on this test?
Thanks for making me aware that 21.0.6 released. I was going to check next week. I tested OpenJDK21U-jdk_x64_windows_hotspot_21.0.6_7.zip which also exhibits the exact same problem.
Exception java.awt.AWTError: no screen devices
@RealCLanger @jerboaa I can confirm that my issue is gone with the following EA build: OpenJDK21U-jdk_x64_windows_hotspot_21.0.7_1-ea.zip Obtained from: https://api.adoptium.net/v3/binary/latest/21/ea/windows/x64/jdk/hotspot/normal/eclipse
Thank you for your work.
There is just one question remaining. We also attempt to run our software against the latest JDK to see problems in advance before actually updating. With JDK 23 the issue persists. I do not need a fix for JDK 23 (or even 24), however how can I expect this to behave in JDK 25 which is the presumed next LTS? Any Information would be much appreciated.
however how can I expect this to behave in JDK 25 which is the presumed next LTS? Any Information would be much appreciated.
That's probably best for @RealCLanger to answer. I'd expect it to be different, but with an escape route for your use-case.
I'm planning to work on a fix for https://bugs.openjdk.org/browse/JDK-8336862 that would allow using "-Djava.awt.headless=false" to restore the old behavior. Hopefully in time for JDK25.