RFR: 8356049: Need a simple way to play back a sound clip [v5]

[Phil Race]

On Fri, 16 May 2025 22:01:11 GMT, Phil Race <prr at openjdk.org> wrote:

>>>The API calls are best protected this way just like the ones in AudioClip were. There's no advantage in removing them.
>> But previously it was protected by methods in the non-public JavaSoundAudioClip, which extended AudioClip. Now SoundClip wraps JavaSoundAudioClip with the same results. Moreover, previously synchronized was not part of the public API, now it is.
>> 
>> One of the benefits to remove them is that it will not be possible to abuse synchronized(SoundClip) which will block execution of its methods.
>
>> > The API calls are best protected this way just like the ones in AudioClip were. There's no advantage in removing them.
>> > But previously it was protected by methods in the non-public JavaSoundAudioClip, which extended AudioClip. Now SoundClip wraps JavaSoundAudioClip with the same results. Moreover, previously synchronized was not part of the public API, now it is.
>> 
>> One of the benefits to remove them is that it will not be possible to abuse synchronized(SoundClip) which will block execution of its methods.
> 
> That is no different than with the applet AudioClip .. it doesn't matter whether it is in the API doc, they are all synchronized. And I don't know why an app would hold a lock that prevents itself from working.
> We can later - meaning in another release - remove synchronized if there's a compelling reason to do so, but I would have thought it better to be explicit about this - unlike applet AudioClip.

> Hmm I did not see all this responses for yesterday...

I umm went to add new comments today and it looked like I did not submit a previous batch of pending replies

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24991#discussion_r2093722549