On Fri, 16 May 2025 22:01:11 GMT, Phil Race <p...@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
