On Sun, 25 May 2025 04:56:14 GMT, Sergey Bylokhov <s...@openjdk.org> wrote:
> possibly we can extend this by two group of methods `asyncPlay/play` and > `asyncLoop/loop` to make it easy to use in a different situations? There are probably going to be zero to a handful of apps anywhere that use this API without a UI. And such an app which is quite focused on the sound playing is quite capable of managing the lifecycle as part of that. The needs/uses I see for this API are in UI apps - which aren't about to exit because a clip ends. For example an audible alert, or effect, reading out tooltip messages (like an AT would do). Perhaps occasionally a longer clip. So in almost all such cases apps just want to call play() and have it not block and let it end naturally, and there's no need to worry about any effect on app termination. Playing in a loop is likely be much less common that just playing once. And if you use loop() and it blocks the thread then you've either got to spin up another thread for when you want to stop it, or more likely call it in a different thread to begin with, so that's harder to program and you might as well not use the synchronous version and probably won't. The sole use case is that single thread main program without a UI and that's not enough reason to do it. Also migrating could be a bit harder if it was exactly the way round you suggested. playAsync() is what play() does today .. so you'd not want to do change that And a blocking play() means it couldn't be called on the EDT - might well make migrating to this API harder, so I think few cases would want to block. So in summary, I don't see any need to add variants that block by any name. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24991#issuecomment-2907933747
