>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 to the application.
I haven't completely traced it, but it looks like the java.net
implementation will fall back to returning the
content as a stream of bytes.
From what I have found so far, MultimediaContentHandlers returning any
of null, an internal class,
a new external class would be OK for the audio cases.
This is because we don't have any internal JDK code, or JCK tests that
reply on this.
Well .. we do have two regression tests, but because they used
(expected) AudioClip they've
been migrated to use SoundClip as part of the Applet API removal.
However if I did the same for any of the image types, we'd have failures
of all the above cases.
The java.beans implementation uses it .
For the audio cases, if I return SoundClip it is possible for
application code to migrate,
just as I did for the two regression tests. But if I return null, they
have a bigger migration issue.
Perhaps even if these APIs still have a use for applications which
install their own handlers and
so have knowledge about it.
For applications that expect an ImageProducer, or an AudioClip, they
must have worked out
what to expect by inspection - and this is going back to JDK 1.0 / 1.1 days
The docs have always (since 1.0) said
'The|instanceOf|operation should be used to determine the specific kind
of object returned.'
Perhaps we can consider deprecating [*] (and later removing) the
MultimediaContentHandlers ?
After all if you have a jlinked image w/o the desktop module, you'll not
be able to us them anyway.
[* I've no idea how you publicly deprecate an internal SPI provider.]
-phil.
On 6/15/25 11:26 AM, Alan Bateman wrote:
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 interact with
this. It's also very possible that there are usages that just assume
an InputStream.
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.
And I can without too much work return a SoundClip, and that offers
the same migration path
as for direct API uses of AudioClip, so may be it is the best short
term thing, whilst a longer term
deprecation is worked out ?
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.
-Alan
