Lamar Owen wrote:
This isn't something you have to guess about. There is a compatibility
test.
Have you run any tests against icedtea? Which specific ones failed? Were
bugs filed in bugzilla about them?
No, I don't see the point of replacing something that works with
something not already proven to be better.
There are different versions with different tests. Sun is the authority
on this unless that have given that up recently. The fact that this
isn't clear shows just how badly the fake versions have damaged the name.
We here have had Java compatibility problems with this app since before gcj,
icedtea, or other FOSS solutions were available. The most notorious, of
course, was Microsoft's java, which didn't work at all.
So you do understand the damage that shipping incompatible versions
causes...
We learned that we
had to specify a particular JRE, and we provide information about this issue
during our training workshops. This is just the applet; the servlet is even
more version-sensitive (we are doing telescope control using custom hardware;
JRE/JDK upgrades are very touchy, even inside a major JDK version).
Even Sun could have done a better job with versioning the code and
providing backwards compatibility.
That's a different - and solvable - issue. If a replacement shell did
something different internally, like removing quotes before expanding
wildcards you'd get the kind of damage that an incompatible java
interpreter can do.
Ever try a real Korn shell on different platforms?
I used it on AT&T sysvr4, but only with Bourne-compatible syntax since I
didn't expect it to be available everywhere.
Specifically, ever tried
it on an Apollo DomainOS 10 or later system?
No - again I don't see the point of using something incompatible...
You'd hate that system;
depending upon the setting of an environment variable, you had different
shells, different sets of programs, and different behaviors (SysV, BSD, or
Aegis).
But that's a different story.
Did any of the settings fail with Bourne-compatible syntax? I've always
used perl for the things I didn't expect /bin/sh to handle portably with
Bourne shell syntax. Other than command line editing, the ksh
extensions weren't compelling enough to give up portability.
--
Les Mikesell
lesmikesell@xxxxxxxxx
