OK. So +1 from me.
-phil
On 03/26/2017 05:56 AM, Sergey Bylokhov wrote:
An issue with this maybe that access to the desktop is required
in order to access the audio device even if it is there as
that is how permissions may be set up to authenticate access
and limit it to a single user.
In this case we will check that the proper exception will be thrown.
So tests being run in a non-headful environment - not quite
the same thing as -Djava.awt.headless=true may be skipped
even on systems that have audio.
This is how it worked before the fix, because these tests were
skipped, if there is no display, but the user had an access to the
audio system.
Were you logged in only as a remote user when executing these tests
and if so did they have audio access if there was such a device ?
I have checked intersections of:
- The user connect locally/remotly
- The user has an access to the Display or not.
- The user has an access to the audio system or not
The tests will work properly when the user have correct access to the
audio system. In other cases it will no-op.
The combination of these factors and a lack of actual audio device
may mean that we have all these tests being a useless no-op.
-phil.
On 3/25/17, 10:29 AM, Sergey Bylokhov wrote:
Hello,
Please review the fix for jdk9.
Some tests in JavaSound were marked by @headful key, but none of
them use UI (headful toolkit).
Looks like the root cause was in absent audio cards in test systems,
and the tests were not ready for that.
Example:
http://mail.openjdk.java.net/pipermail/sound-dev/2015-August/000328.html
I have checked updated tests in the system with and without Display
and AudioCard.
If the tests will fail on some of our tests systems then the reason
is unrelated to the headful toolkit and should be reported as a
separate CR.
Bug: https://bugs.openjdk.java.net/browse/JDK-8177560
Webrev can be found at:
http://cr.openjdk.java.net/~serb/8177560/webrev.00
<http://cr.openjdk.java.net/%7Eserb/8177560/webrev.00>
