Windows AWT: support for running applications without display?

Briemann, David david.briemann at sap.com
Thu Jun 12 08:12:22 UTC 2025


Hi,

I was recently asked to investigate this issue: https://bugs.openjdk.org/browse/JDK-8341294

Let me give a summary of the problem here (copied from newest comment in this ticket):



# The problem

A bugfix (https://bugs.openjdk.org/browse/JDK-8185862) changed the behavior of AWT applications on Windows when no display is available.

## Status Quo (HEAD, > jdk21)

If an AWT application is started on a Windows system that does NOT have a display available it will run into:

```
Exception in thread "main" java.lang.InternalError: Could not update the devices array.
```

Setting `-Djava.awt.headless=false` does not affect this outcome.

## Earlier behavior (<= jdk 21)

If an AWT application is started on a Windows system that does not have a display available it will just start / continue to run.

## Expectations

Some JDK users were affected by this change because they run applications in Windows VMs without display.
They want the old behavior back. Maybe by (ab)using setting the flag `-Djava.awt.headless=false` explicitly on startup.

## Observations

The often mentioned old behavior may be sufficient to "just run" the application without display, however it is bugged.
If you actually observe what is drawn to the screen when it reappears (e.g. by reconnecting to a remote host),
then it can be observed that some UI elements are silently not drawn to the window, e.g. the "label" of a `ProgressMonitor`.

## What to do?

Since I am neither a Windows user nor a an AWT expert I bring this up here for discussion. My current opinion is that the JVM should not revert to the old behavior. As stated above the old behavior is buggy. That certain old tests/workflows rely on this buggy behavior does not warrant going back in newer JVM versions in my opinion.
I know there are all kinds of historically grown software stacks out there but if these tests / workflows really cannot be changed, maybe using a virtual display driver would be a workaround ( see e.g. https://github.com/VirtualDrivers/Virtual-Display-Driver ).




I wanted to bring this to the attention of AWT devs. I was in contact with a Windows dev who is affected by this problem and his scenario boils down to this:

  *   They are using AWT components in the backend to draw things to buffered images which are then delivered to customers as PNG.
  *   They use a framework called BIRT, to create PDFs and Word documents, which in turn uses AWT components.
  *   They cannot run their program because it runs into exceptions when e.g. creating the window. (in a windows container, without display)

Since I am neither a Windows nor AWT dev I wanted to ask for your input here. Do you think these scenarios should be supported? If yes how? Because just “reverting” to the old behavior does not seem like a good idea (at least to me). To my understanding this would mean that silently some things are just not drawn.


Thanks for reading,
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250612/43afa9f9/attachment-0001.htm>


More information about the client-libs-dev mailing list