Hi Bob,
I do agree on a higher level, but not for this particular case.
Improving an established cross platform API (like Java Sound) is never
easy because it must stay compatible for the users. With "users", I
mean programmers using Java Sound, and their users. Here, on this
list, we discuss the underlying implementation. Often enough it's
painful and complicated to still fulfill the spec of 15 years ago. But
the upside is that these efforts guarantee that using Java Sound
remains the same and even 15 year old JS programs still work the same.
In this particular case (the NPE thing), I don't think anything is
broken: the "old" implementation works and is "according to
specification". I just want to ensure that it does not open a loophole
to become broken!
On a side note, it is very important to protect users from poorly
programmed, or broken, or malicious plugins (i.e. SPI's). That's why
we catch the NPE and don't pass it on to the unsuspecting user.
> Personally, I've always thought the concept of a mixer is
> flawed, because it's inherently a non-portable concept, (...)
Hmmm, I cannot follow here. For me, only the name "Mixer" is
non-portable. If you think of it as "AudioDevice" or "AudioCard" than
Java Sound is pretty much the same as any other audio hardware
abstraction. The same is true for the naming of SourceDataLine
("OutputStream") and TargetDataLine ("InputStream").
> When I write a Java Sound program, I want the same level
> of simplicity.
It seems to me that you imply that you need to implement an SPI in
order to play back a sound? That would be horrible indeed!
But, as I'm sure you know, if you need simplicity, just get a Clip,
load a file into it, and play: 3 simple lines of code. If you want to
do, for example, low latency VoIP or a software synthesizer, things
become a bit more complicated, but that's the same for any audio API
I've worked with.
For me, it's important that the simple things are /simple/ to do, and
the advanced things are /possible/ to do.
> 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?
The idea is tempting: a modern audio API in Java. But frankly, when
thinking about it, it would most likely boil down to little more than
JS class renaming/consolidating/cleaning. If you look at other audio
API's, you'll always find the concepts of device, stream, audio
format, file, codec -- just as in Java Sound. The main difference is
that JS uses strange naming and overly complicated arrangements...
What I don't see at all is the missing platform portability in Java Sound?
Thanks,
Florian
On 24.10.2015 02:12, Bob Lang wrote:
> On 23 Oct 2015, at 19:56, Florian Bomers <javasound-...@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?
>
> Bob --
>
--
Florian Bomers
Bome Software
everything sounds.
http://www.bome.com
__________________________________________________________________
Bome Software GmbH & Co KG Gesellschafterin:
Dachauer Str.187 Bome Komplementär GmbH
80637 München, Germany Geschäftsführung: Florian Bömers
Amtsgericht München HRA95502 Amtsgericht München HRB185574
