Withdrawn: 8275170: Some jtreg sound tests should be marked headful

[duke]

On Fri, 22 Oct 2021 19:01:27 GMT, Phil Race <prr at openjdk.org> wrote:

> This fix adds "headful sound" keywords to a number of javax/sound jtreg tests
> 
> The jtreg javax.sound tests are written in such a way that if a needed audio device
> or other platform resource is not available, they just exit with a "pass" for the test.
> It is as if headful tests just swallowed HeadlessException and issued a pass.
> If we allowed that we'd be effectively testing almost nothing of real importance.
> 
> Currently almost  all sound tests have no keyword like "headful" to indicate they
> may need access to a hardware resource to do anything useful so a similar
> situation arises there except when someone runs those tests manually on
> a local system which has audio devices.
> 
> Of course "headful" and "audio device" aren't exactly interchangeable terms
> but if tests are allowed to be run - or worse usually or always run - in a situation
> where they potentially are on a system without an audio device (a headless VM) or are running in
> a session which doesn't have full desktop access - which may in some
> cases be how audio device access is granted, then they are more likely
> to be running in this scenario where the testing isn't valid.
> 
> Another point is that headful tests must be run one at a time - no concurrency because
> you can't have multiple tests moving the mouse at the same time
> Whereas for headless tests, a test harness may choose to run concurrently - perhaps even in the same VM
> When tests that really need access to an audio device are run it is probably safer to consider
> the headful attribute as implying one test at a time is best .. granted on a desktop it isn't
> usual for a single app to be able to monopolize access to a speaker, but for input devices
> that is what you'd generally expect.
> 
> By no means am I sure that the tests being updated here are the full set that need tagging.
> There are a lot of tests and they are all known to pass on systems with NO audio
> devices, so the search has been for tests which call APIs which will definitely
> need access to some device in order to do anything useful.
> So likely there are more to be added - either by a reviewer pointing them out or by later discovery.
> Alternatively we could mark ALL sound tests headful .. but given where we are starting from
> that might be erring unnecessarily far in the opposite direction.
> 
> By adding both headful and sound keywords it gives options to someone who
> wants to identify the tests and perhaps run just tests which need "sound" on some
> config they know supports audio but isn't headful.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6086