<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<br>
>A migration from AudioClip to SoundClip would require all usages
to change too.<br>
>I think for now that it should be okay to just the mapping from
MultimediaContentHandlers so that it returns null.
<br>
<span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: -webkit-standard; font-size: medium; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; display: inline !important; float: none;"><br>
For clarity, this handler/provider returning null does not mean
that null is what is returned to the application.<br>
I haven't completely traced it, but it looks like the java.net
implementation will fall back to returning the<br>
content as a stream of bytes.<br>
<br>
</span>From what I have found so far, MultimediaContentHandlers
returning any of null, an internal class,<br>
a new external class would be OK for the audio cases.<br>
This is because we don't have any internal JDK code, or JCK tests
that reply on this.<br>
Well .. we do have two regression tests, but because they used
(expected) AudioClip they've<br>
been migrated to use SoundClip as part of the Applet API removal.<br>
<br>
However if I did the same for any of the image types, we'd have
failures of all the above cases.<br>
The java.beans implementation uses it .<br>
<br>
For the audio cases, if I return SoundClip it is possible for
application code to migrate,<br>
just as I did for the two regression tests. But if I return null,
they have a bigger migration issue.<br>
<br>
Perhaps even if these APIs still have a use for applications which
install their own handlers and<br>
so have knowledge about it.<br>
<br>
For applications that expect an ImageProducer, or an AudioClip, they
must have worked out<br>
what to expect by inspection - and this is going back to JDK 1.0 /
1.1 days<br>
<br>
The docs have always (since 1.0) said<br>
'<span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: -webkit-standard; font-size: medium; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; display: inline !important; float: none;">The<span class="Apple-converted-space"> </span></span><code style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">instanceOf</code><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: -webkit-standard; font-size: medium; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; display: inline !important; float: none;"><span class="Apple-converted-space"> </span>operation should be used
to determine the specific kind of object returned.'<br>
<br>
Perhaps we can consider deprecating [*] (and later removing) the </span>MultimediaContentHandlers
?<br>
After all if you have a jlinked image w/o the desktop module, you'll
not be able to us them anyway.<br>
<br>
[* I've no idea how you publicly deprecate an internal SPI
provider.]<br>
<br>
<br>
-phil.<br>
<br>
<div class="moz-cite-prefix">On 6/15/25 11:26 AM, Alan Bateman
wrote:<br>
</div>
<blockquote type="cite" cite="mid:a7989e6c-21ac-410b-aa8f-738be4518564@oracle.com">On
15/06/2025 17:33, Philip Race wrote:
<br>
<blockquote type="cite">Perhaps these APIs should be deprecated
(for removal) ?
<br>
</blockquote>
<br>
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.
<br>
<br>
<blockquote type="cite">
<br>
For 30 years, AudioClip has been the only public type that this
API returned for audio data.
<br>
Clearly that won't be possible after it is removed.
<br>
<br>
SoundClip is the replacement for public uses of AudioClip so it
is the obvious replacement.
<br>
And I can without too much work return a SoundClip, and that
offers the same migration path
<br>
as for direct API uses of AudioClip, so may be it is the best
short term thing, whilst a longer term
<br>
deprecation is worked out ?
<br>
</blockquote>
<br>
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.
<br>
<br>
-Alan
<br>
</blockquote>
<br>
</body>
</html>