<Sound Dev> [9] Review Request: 8135100 Behavior of null arguments not specified in javax.sound.sampled.spi

Bob Lang bob.lang at blueyonder.co.uk
Sat Oct 24 00:12:32 UTC 2015

On 23 Oct 2015, at 19:56, Florian Bomers <javasound-dev at bome.com> wrote:

> Hi Sergey,
> I guess you're right and the second loop will never be executed if we
> will always have the default mixer providers.
> Removing the NPE catch clause, however, will still cause a backwards
> incompatibility, because if a poorly programmed MixerProvider gets
> installed which throws NPE for whatever reason (might also happen when
> "info" is non-null), now AudioSystem.getMixer() will throw NPE, where
> it previously worked.
> I agree that it's harder for debugging mixer providers if NPE is
> ignored. Other than that, I don't see any problem with keeping the NPE
> catch for backwards compatibility's sake. Even if just theoretical...
> But you never now, companies might be using poorly programmed in-house
> software or the like.
> Thanks,
> Florian

So, it's broken if you do the right thing and it's broken if you don't??

There comes a point in any software project where years of cumulative amendments, fixes and modifications make the code so fragile that it's no longer modifiable. 

Personally, I've always thought the concept of a mixer is flawed, because it's inherently a non-portable concept, which should be anathema in a language that has portability as its main goal.  The Mixer SPI only works when the programmer writing the code actually understands what's going on and the implications of any choice - and frankly, how often does that happen?  When I write a graphics program, I don't have to worry about the specific capabilities of the specific video card on the user's specific computer - all that detail is (quite rightly) hidden from me.  And because it's hidden from me, my program works on any desktop/laptop computer. When I write a Java Sound program, I want the same level of simplicity.  It should be possible, because sound is inherently simpler than video - yet Java Sound makes it far more complex. 

Is it time to freeze and deprecate the existing Java Sound, and start again with a new design, with cross platform portability as its major aim?


More information about the sound-dev mailing list