java.net.URLConnection.getContent()

[Philip Race]

 >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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20250616/f94b40fc/attachment-0001.htm>