RFR: 8301846: Invalid TargetDataLine after screen lock when using JFileChooser or COM library [v3]

[Sergey Bylokhov]

On Wed, 26 Jul 2023 23:29:41 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> > > 3. Do another CoInitialize before call  :- not a good approach
>>> > 
>>> > Yet it does not break the rules: you can initialise COM, call an API and then call [`CoUninitialize`](https://learn.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-couninitialize). If you don't keep any references to COM objects, it is valid.
>>> 
>>> Tried this approach and it works, we may need to do the similar approach for another function `DAUDIO_GetDirectAudioDeviceDescription` because this also calling `DirectSoundEnumerateW `& `DirectSoundCaptureEnumerateW `
>> 
>> Does this approach return full names for devices, without truncating them?
>
> But if that code requare com my expectation would be that they call CoInitialize/CoUninitialize.
> 
> This CoInitialize initially was added here https://bugs.openjdk.org/browse/JDK-6950553 (check the stack trace),
> https://github.com/openjdk/jdk/commit/b8b9c35567919f9f375cc3610d823524cf5b8582 can we check that the DAUDIO_GetDirectAudioDeviceDescription  is really uses that com object w/o initialisation?
>>1. Call CoInitializeEx, enumerate devices, and call CoUninitialize.
>>2. Create an executor service which initialises COM on its worker thread, enumerate devices on the worker thread and return the devices. The worker thread may terminate (after it calls CoUninitialize) if it doesn't receive more requests in a period of time.
> 
> We can try reuse the "Filechooser.invokeCom" machinery, but I do not think I like it.

is it possible that our "::CoInitialize(NULL);" prevents the ::CoInitializeEx(NULL, COINIT_MULTITHREADED); in the lib later?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14898#discussion_r1275577287