[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Java problem

Lamar Owen wrote:

This isn't something you have to guess about.  There is a compatibility

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 gmail com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]