Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Regression "no screen devices" in Windows Containers #1222

Open
1 task done
AlexanderSchuetz97 opened this issue Jan 22, 2025 · 8 comments
Open
1 task done

Regression "no screen devices" in Windows Containers #1222

AlexanderSchuetz97 opened this issue Jan 22, 2025 · 8 comments
Labels
bug Something isn't working jbs:reported Someone from our org has reported it to OpenJDK

Comments

@AlexanderSchuetz97
Copy link

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?

  • 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 AlexanderSchuetz97 added the bug Something isn't working label Jan 22, 2025
@karianna
Copy link
Contributor

@AlexanderSchuetz97 Are you able to try with 21.0.6 next week when it comes out and report back here?

@jerboaa
Copy link

jerboaa commented Jan 23, 2025

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 #1203

@AlexanderSchuetz97
Copy link
Author

AlexanderSchuetz97 commented Jan 23, 2025

@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.

@karianna karianna added jbs:reported Someone from our org has reported it to OpenJDK and removed Waiting on OP labels Jan 23, 2025
@michael-newsrx
Copy link

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?

@AlexanderSchuetz97
Copy link
Author

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.

@michael-newsrx
Copy link

@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?

@AlexanderSchuetz97
Copy link
Author

AlexanderSchuetz97 commented Jan 24, 2025

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
Copy link

I'm working on a backout of JDK-8185862: JDK-8348625

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working jbs:reported Someone from our org has reported it to OpenJDK
Projects
None yet
Development

No branches or pull requests

5 participants