So once it was explained to me that this headless VM exec's
another headful VM instance it started to make sense ..
+1
-phil.
On 03/26/2018 07:02 PM, Sergey Bylokhov wrote:
On 26/03/2018 17:50, Philip Race wrote:
I presume the headful keyword means thie can't be run in our nightly
tests ..and
isn't supposed to be run in headless mode, so I am a bit puzzled by
the change.
I also don't understand why it would be "random".
An updated test just emulates the problem, it run the first instance
using "-Djava.awt.headless" and then unconditionally tries to change
the system display mode, this causes an exception in the headless
instance.
This bug cause the random failures of our headless tests
Here I have referenced any other tests in nightly, which fails if we
get such notifications from the OS.
* @key headful
* @summary Tests that no exception is thrown when display mode is
changed
* externally
* @compile UninitializedDisplayModeChangeTest.java
DisplayModeChanger.java
* @run main/othervm UninitializedDisplayModeChangeTest
+ * @run main/othervm -Djava.awt.headless=true
UninitializedDisplayModeChangeTest
*/
-phil.
On 3/20/18, 11:48 AM, Sergey Bylokhov wrote:
Hello.
Please review fix for jdk11.
Bug: https://bugs.openjdk.java.net/browse/JDK-8198335
Webrev can be found at:
http://cr.openjdk.java.net/~serb/8198335/webrev.01
This bug cause the random failures of our headless tests. The reason
is that we try to notify the
GraphicsEnvironment(HeadlessGraphicsEnvironment), which does not
implement DisplayChangedListener, about display change.
It is possible to skip this notification for headlesGE only, but I
think that it is better to make instanceof before cast to
DisplayChangedListener, usually we use this pattern in other places.
PS. Note that WToolkit.paletteChanged and WToolkit.displayChanged
use different threads for notifications, I have created a bug to
investigate this: https://bugs.openjdk.java.net/browse/JDK-8199881
