On 16/06/2025 19:48, Philip Race wrote:
>A migration from AudioClip to SoundClip would require all usages to
change too.
>I think for now that it should be okay to just the mapping from
MultimediaContentHandlers so that it returns null.
For clarity, this handler/provider returning null does
>A migration from AudioClip to SoundClip would require all usages to
change too.
>I think for now that it should be okay to just the mapping from
MultimediaContentHandlers so that it returns null.
For clarity, this handler/provider returning null does not mean that
null is what is returned t
On 15/06/2025 17:33, Philip Race wrote:
Perhaps these APIs should be deprecated (for removal) ?
Maybe but would require a lot of analysis to understand impact as there
are several ways to configure content handlers and there are stream
handlers that exist outside of the JDK that might interac
Perhaps these APIs should be deprecated (for removal) ?
For 30 years, AudioClip has been the only public type that this API
returned for audio data.
Clearly that won't be possible after it is removed.
SoundClip is the replacement for public uses of AudioClip so it is the
obvious replacement.
On 13/06/2025 23:11, Philip Race wrote:
java.net.URLConnection has
public Object getContent();
It uses the desktop module to find handlers for image and audio data
Briefly, the desktop module
"provides java.net.ContentHandlerFactory with
sun.awt.www.content.MultimediaContentHandlers
