Java problem

[Les Mikesell]

Lamar Owen wrote:

>>> 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.
> 
> What is 'better'?  Sorry, I know that sounds like splitting hairs, but there 
> is no way of proving something is 'better' (in the most amorphous sense of 
> that already amorphous word) without releasing it. 

If you can't measure it, you can't improve it.  And if you haven't 
measured it, why, if you release it, should someone install it?

> That's why you have 
> alternatives, and that's why the system is an open one.  That's why it is a 
> built-in possibility to replace the provided java infrastructure with the Sun 
> one.

I don't understand how a bizarre and mostly undocumented series of 
symlinks pointing to symlinks 'builds in' the possibility to replace 
things.  Did 'rm' stop working?

> So why don't you run the tests and see how good or how bad it is, rather than 
> wasting time griping about something that isn't going to change unless and 
> until Sun releases under a redistributable (by Fedora) license?
> 
>> So you do understand the damage that shipping incompatible versions
>> causes...
> 
> Of course I do.  But I also understand the reasons that IcedTea is in F8 
> instead of a Sun java.  I also understand that it is not hard to get a Sun 
> java into F8 (once a few things are worked around, and the systems provided 
> in F8 are used).
> 
>> Even Sun could have done a better job with versioning the code and
>> providing backwards compatibility.
> 
> And that's the point: java compatibility issues are not isolated to IcedTea or 
> gcj.

But they are compounded by additional versions with no standards 
verification.

>>> 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.
> 
> I mention the real Korn shell since it is even available for F8; also on 
> Solaris, HP-UX, and others.  Particularly since Bash is not a Bourne shell 
> (strictly speaking), I use as an example a shell that can be used to isolate 
> compatibility differences to things outside the shell itself.
> 
>>> 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).
> 
>> Did any of the settings fail with Bourne-compatible syntax? 
> 
> Yes, since the default behavior (of the version I had) was to make the 
> c-shell /bin/sh if in BSD mode, and the Bourne shell /bin/sh if in SysV mode; 
> a shell script could change the environment variable within itself, then 
> morph from a Bourne script to a csh script, then change the envvar back and 
> resume processing as a Bourne script.  

Yes, you were right - I hated anything that made csh a default shell.

> Yes, that is very broken, but it was the case on the DN3500 with DomainOS 10.2 
> (with AutoCAD on it; that was why the machine existed) I worked on.  The 
> $PATH had the envvar embedded in various paths; the default /bin 
> (and /usr/bin) was a variably symlinked (yes, an embedded envvar inside the 
> symlink!) directory, with three possible targets: one the SysVR3-compatible 
> one, one the 4.3BSD-compatible one, and one the Aegis (the previous Apollo 
> environment) one.  Oh, and Apollo DomainOS had a great gui, but it wasn't X11 
> (which had to be added separately): instead of xterms, you had what were 
> known as 'pads' which are much like xterms of serious steroids.  It was a big 
> enough target that AutoDesk built for it (in the late 1980's).
> 
> People who complain that Linux distribution differences are like the old unix 
> war-era differences don't know what they're talking about; Ubuntu, OpenSUSE, 
> Fedora, etc are all much more alike than they are different; the various 
> competing Unixen of the late 80's and early 90's were more different than 
> they were alike.  Even in the case of SCO Unix versus SCO Xenix; same 
> company, quite different Unix variants (Xenix, of course, being the 
> Microsoft-licensed Unix derivative sold to the old SCO).

Still, if you can't run the same binaries, scripts, and java-bytecode 
across them, it doesn't matter that they share a tux logo somewhere.

-- 
    Les Mikesell
     lesmikesell at gmail.com