[aprssig] followup on Rant about cross platform

[Jim Lux]

I respect Gregg's enthusiasm for Java, his software development 
experience, and his philosophical desire for wider universality of 
software generated by and for hams.  I readily concede that he has 
orders of magnitude more experience with Java than I do, but that's 
really the point.  Most hams developing software are more like me 
than Gregg, and that drives the selection of development environment.

The idea I was trying to develop was that people developing software 
for love (which is the vast majority, if not all, of amateur radio 
software) have to make decisions about how to allocate their scarce 
resources.  The easy decision (because developers for love tend to 
want to minimize the work making their baby) is to work in what you 
know, and, statistically, that's not likely to be Java (no matter how 
wonderful it may or may not be).

When you talk of DSP code (e.g. the example Gregg gave of a PSK31 
engine, or some other modem implementation), the likely coder is 
someone who is almost certainly not from the Java world, if only 
because Java isn't particularly popular for these applications, 
especially in an embedded environment. While there are high 
performance Java implementations on the PC platform, the same is 
probably not true for, say, TMS320, SHARC, or even various 8 bit MCUs 
that have been pressed into service for DSP applications over the 
years.  A cursory google for "Java DSP" turns up lots of little demo 
applications to show how various DSP algorithms work, and a fair 
amount of stuff on how you can use Java to effectively glue together 
native code DSP functions.

This is not to say that you couldn't write hard-real-time DSP code in 
Java (Ii suspect you could, with sufficient resources), but rather 
that, most likely, the code base they would be starting from is more 
likely to be in ASM or C.  There is a lot of work involved in writing 
modem code, especially to handle all the corner cases and deal with 
the idiosyncracies of the surrounding environment, while still giving 
good performance, and most people start with something that they know 
works somewhere, and then modify it for the new platform.  As they 
say, old habits die hard.

I'll also comment that in many of the DSP projects I've been involved 
in, the non-determinism of timing in standard Java would make it an 
out-of-the-gate non-starter, even if it were available for the target 
processor.  Sure, one could probably come up with a custom 
implementation of the JVM/JRE with appropriate determinism, hooks to 
the hardware, etc., but then, you're not in the "write once, run 
everywhere" model anymore.  I readily confess that I know next to 
nothing about how one might even start doing this in Java. I 
understand that there are efforts being made to create a "real-time 
Java", but, it's nowhere near as mature as the existing body of 
knowledge in Asm or C (better the devil you know, etc.). But this 
gets back to the point about people tend to want to work in the 
environment they are familiar with, which, statistically, is not Java.

So, it's a pretty bold request to ask a volunteer to take on not only 
coding/porting up some sort of modem (a non-trivial task in itself, 
but one that is small enough to be done in a reasonable time ), but 
also to ask that they learn a whole new computing environment, with 
just as many idiosyncracies as, say, Windows.  You'd probably have to 
show that the new environment provides some really useful 
functionality (to the volunteer) that they currently don't have 
available, or that is a pain to get.  That is, it will make their job 
noticeably easier if they adopt, for example, Java. An appeal to an 
abstract altruism: "it will help society in the future" is a much 
harder sell.  It's true you've at least got them volunteering in the 
first place, so it's not a totally lost cause.  There's a similar 
discussion going on in the SDR-1000 world about the adoption of a 
language called Erlang.

Gosh, people are still developing applications for ham radio that are 
based on MS-DOS, and probably modified from code originally written 
for a Z80 running CP/M.  In that context, Java is just a young 
stripling with a lot of growing left to do.  And, I see ham radio 
software moving towards a more "componentized" implementation, with 
cleaner interfaces among components.  I really shouldn't care what 
langauge the PSK engine is written in, as long as it's available for 
my platform and it has the right hooks to make it work.

Jim Lux, W6RMK