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 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.
Right, a ContentHandler can return null but the
URLConnection::getContent API always returns something when content can
be fetch from the URL. URLConnection.UnknownContentHandler is the lender
of last resort.
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.
I agree that returning a SoundClip gives a migration path, it's more
defensible than not mapping.
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.
In the jlink case, you'd have to include java.desktop if the
application, or a library, has a static depending on java.awt.image.*
types. So yes, you would get different behavior depending on whether the
java.desktop module is in the run-time image but only if the application
isn't using instanceof.
No objection if we try to work towards dropping these mappings, just not
clear how much testing there is with EA builds to shake out any common
usages that we can't think of.
-Alan
