On Thu, 22 May 2025 22:31:33 GMT, Phil Race <p...@openjdk.org> wrote:
>This API is not so different than the Applet AudioClip because it is a simple >replacement for that which is intended to be used by desktop apps - not >browsers any more. Sure the implementation here is identical to the decades old Applet.AudioClip (deprecated for 9 years!), but is that really a good thing? Shouldn’t we take this opportunity to improve the API or at the very least, document its limitations and intended use more clearly? JavaFX, for example, is better documented. There may also be other patterns or audio playback features "in the wild" Java that would be worth considering as part of a more modern solution. Regarding the current patch, I still have a few questions and suggestions: - Why is IllegalArgumentException used instead of NullPointerException? The entire sound/media stack consistently uses NPE for null checks, and most recent JavaSE APIs (e.g., FFM, StableValue, ScopedValue, etc.) follow this pattern. NPE is just better. what are the pros for IAE? - Why we do not document that the application will not exit if a clip is playing (and will never exit if loop() was called)? This is an important behavioral detail, similar to what is documented in [AWT threading issues](https://github.com/openjdk/jdk/blob/fdda7661906eab63d939e9f482449e21cc143c8f/src/java.desktop/share/classes/java/awt/doc-files/AWTThreadIssues.html#L108). - The synchronized keyword appears unnecessary in the current implementation. It can be dropped now and reconsidered later - possibly with another concurrency primitives. - The multithreaded behavior and asynchronous nature of the API are not described. - There’s no mention of preloading behavior. For example, JavaFX explicitly documents this. - The tests don't cover the next part of the spec: > “If the implementation does not find a suitable output device for the > data, playing the clip will be a no-op.” ------------- PR Comment: https://git.openjdk.org/jdk/pull/24991#issuecomment-2902853177
