Perhaps these APIs should be deprecated (for removal) ?
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 ?
-phil.
On 6/14/25 12:21 AM, Alan Bateman wrote:
On 13/06/2025 23:11, Philip Race wrote:
java.net.URLConnection has
public Object getContent();
It uses the desktop module to find handlers for image and audio data
Briefly, the desktop module
"provides java.net.ContentHandlerFactory with
sun.awt.www.content.MultimediaContentHandlers;"
That knows about several audio and image mime types.
And URLConnection passes a mimetype string to the ContentHandlerFactory
If it is one of the mimetypes known to the desktop provider
URLConnection gets returned one of
URLImageSource
java.awt.Image
java.applet.AudioClip
But the return type of getContent() is just java.lang.Object and
nothing is specified.
How does anything use this API ?
The reason this comes up is that when removing the Applet API, this
needs to transition to something
other than AudioClip - but who would notice if it got back null
instead ? Or just a byte[] of the raw data ?
Or something else ?
Is this API actually used ? Or useful ?
This is a JDK 1.0 era API. The intent seems to be to test the return
with instanceof to test for types that the caller can deal with. The
1-arg overload allows the caller to provider an array of the types
that it can deal with. Ironically, the addition of pattern matching
for instanceof and other work on patterns makes it easier to use.
I did a quick search to see if there is a mapping/table anywhere on
MIME type to Java class but don't see it.
In any case, with the removal of java.applet then it can't return an
AudioClip, and existing code that expects an AudioClip won't compile
or run. Looking at JavaSoundAudioClip then it doesn't look like there
are other audio types implemented. I can't case to a SoundClip or
other sound types, right? So I think dropping it should be okay,
meaning null will be returned.
-Alan