And, just to add to this thought: It really rubs me the wrong way that so
many "Java" applications, touting the "Write once, run anywhere" philosophy,
each come with their own JVM as part of the install. IBM is rife with this,
and you can end up with five or six JVM installations on a single server.
Remember the DST patching? This had to be done for each and every JVM, and
if you weren't aware that an application had its own copy, then they didn't
get DST right, and guess who gets blamed (at least initially).

I just ran into this with a product called WaveMaker. The product installed
(rpm file), but wouldn't start. Closer inspection found messages in its logs
about bad binary executables. Sure enough, it had thoughtfully provided its
own version of the JVM, because obviously, no system administrator could
possibly have installed the Java "they" wanted to use. Re-naming their java
directory and substituting a symlink to the "real" java solved the issue and
got the application running... But it'd have been nice if it had the option
to run with the system's own java, or just hadn't come with one at all.

So... Java's become "Write once, run anywhere,... And drag your own JVM with
you to be sure." Sure makes you miss the good ole days when everything was
done in assembler, and you wrote your own applications instead of buying odd
off-the-shelf applications.

-- 
Robert P. Nix          Mayo Foundation        .~.
RO-OE-5-55             200 First Street SW    /V\
507-284-0844           Rochester, MN 55905   /( )\
-----                                        ^^-^^
"In theory, theory and practice are the same, but
 in practice, theory and practice are different."




On 4/10/08 8:27 AM, "McKown, John" <[EMAIL PROTECTED]> wrote:

.
> 
> Uh, if the "Linux software" is a closed source application and the
> vendor does not supply a System z port, then the software will not run
> on Linux on z. Just being a pain-in-the-buttocks (me).
> 

Reply via email to