On Thu, 12 Jun 2025 22:48:14 GMT, Sergey Bylokhov <s...@openjdk.org> wrote:
>> I looked into this when I was doing SoundClip. >> What is actually returned by contract is a ContentHandler which returns an >> Object from its getContent() method >> That Object happens to be a com.sun.media.sound.JavaSoundAudioClip which >> previously implemented AudioClip >> >> This implements relationship isn't there for SoundClip, so the expectation >> of the test that it knows of an exported type that will actually be returned >> is no longer valid. >> >> I don't think it is worth testing that JavaSoundAudioClip is returned. >> >> Possibly we could jsut verify that a non-null handler is returned ? > > As far as I understand, this method should return something that the > application can actually use. Previously, the application could access the > audio data via the AudioClip interface - it wasn’t important that it was > specifically implemented by JavaSoundAudioClip. Now, I believe we should > return a SoundClip object, which can be created (not necessarily via the > public API of the SoundClip/JavaSoundAudioClip classes). I have no idea how applications (or applets) could really have used this URL.getContent() API that just returns an Object. It seems like it was meant to be used by some other part of the larger JDK that was aware of how this was implemented. I am inclined to ask the networking API owners what the purpose and future should be. I also don't particularly like the java.base module (even via this private SPI) calling into the desktop module. When the desktop module isn't present in a jlinked image it will not find a handler and have to do some default thing such as return raw bytes or null. So I can probably return a SoundClip but any code out there that used this was always taking a chance. OTOH we are removing Applet entirely so anyone who was relying on this is out of luck anyway. >> was this comment meant to be on some other (test) code ? > > It is about content handlers we discussed above and its implementation in > awt/www/content/audio/. If we want to support content handlers then it is not > necessary to change this in the test: >>SoundClip clip = (SoundClip) file.toURL().getContent(); Not sure I would do that anyway here. It seems like an unnecessary file->url->file roundtrip with a cast to a type you have to "know". And it was never specified. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2146175203 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2146141458
