[SLL] faking Unix knowledge? pretend to know open source Unix?

[Jesse Keating]

On Thu, 2009-01-15 at 14:42 -0800, Chuck Wolber wrote:
> On Thu, 15 Jan 2009, Jesse Keating wrote:
> 
> [...]
> 
> > However with Java, even though the goal is /supposed/ to be run 
> > everywhere because everything is duplicated in the JVM, 
> 
> You make a good point we should seriously consider your assertion that 
> "because Java everything is duplicated in the JVM". Isn't this the design 
> pattern used in any interpreter though? Otherwise, how do you advertise 
> that you support, oh say for example, file writing and reading? You have 
> to duplicate stuff at some level in order to tailor it to the low level 
> operating system APIs. It's just an abstraction.

There is a difference between writing an abstraction to data, and
replacing data.  I hate to beat a dead horse, but with *nix, in python,
if you want to access timezone data, you eventually get a python
interpreter that is making calls out to glibc to fetch that info.  But
with java, that doesn't happen.  Java has it's own copy of the timezone
data.  Why?  Probably some reason about porting java to other operating
systems which have different ways of getting timezone data.  This is
what I'm harping on, the difference in other languages such as C,
python, perl, et al and java.  The difference between abstract the
system interface to and replace the system interface all together.

> 
> It's the same thing for the Linux kernel. It provides a common interface 
> so that it can work on a lot of different uncommon hardware. In their case 
> though they drew the line at the CPU architecture and then threw in little 
> hacks to detect the CPU variances for a given architecture since not all 
> CPUs implement the x86 instruction set in exactly the same way.
> 
> Thus an app written on a Linux system is "Write Once Run On Any Linux".

But what the kernel doesn't do is create its own "cpu" that everything
must interact with, or it's own real time clock, or.. or...  (not that
java does exactly these things, but the comparison should work)

> 
> > the reality is that almost every application I've come across in java 
> > not only can't traverse platforms such as Unix/Windows, it cannot even 
> > traverse different patch versions of a JVM.
> 
> Yes, but you just boxed yourself into a logical corner there. I can show 
> you plenty of extremely complex Java apps that work great on Windows and 
> *ix without any code changes. I think that proves that WORA can be done.

... but I bet you must use the same vendor java and patch level on
whatever platform you're on.  Also, I don't doubt that such things
exist, I've just never experienced them, despite all the advertising to
the contrary.

> 
> > It wouldn't be so frustrating if the Java mantra wasn't WORA.
> 
> Even though they have not said it, the same goes with Python and any other 
> interpreted language. All thinge being equal, you do not generally say 
> "can I run this app written in Python on my computer". You say "can I run 
> python apps on my computer".

Yes and no.  There are no illusions that you'll have to forward port
python for new versions, or do porting work to move an app to a new
platform.  There is no claim at all of WORA.

> 
> With Java, the problem is compounded with "can I run this app written in 
> Java version XYZ on my computer *AND* did the programmer screw up WORA?". 
> I suspect that if I knew Python really well, I could point out a few 
> examples of how that also applies to Python.

The question has always been for me "which instance of Java was this
WORA written for, and now I'll have to add /that/ version to my
infrastructure to go along with the other 5+ versions floating out
there."  Oh sure it'll run anywhere.... anywhere you have this exact
copy of the JVM for me.  That's neat for code, hell for the admin.  It'd
be the same thing as saying "My application runs anywhere... anywhere
that you can run this virtual image of a RHEL5 install with all my
libraries pre-installed."  Surely it wouldn't be a problem to run 3 or
four of these images, for each application you want to support.  Oh, but
it won't work on RHEL5.2, so you'll have some RHEL5.0, some RHEL5.2,
some Debian <whatever>, but that's OK, they're all virtual machines and
can run on the same "box".  Isn't this WORA thing great?!  I never have
to touch my code again!

-- 
Jesse Keating RHCE      (http://jkeating.livejournal.com)
Fedora Project          (http://fedoraproject.org/wiki/JesseKeating)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
identi.ca               (http://identi.ca/jkeating)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists2.linuxjournal.com/pipermail/linux-list/attachments/20090115/182d8855/attachment.sig