<!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>