On Fri, 9 Apr 1999 19:30:16 +0100, Oliver Fels wrote:
>> Well, I now know why people say "Write once, test everywhere"
>>
>> If the code you write is not correct, sometimes it still produces
>> what seems to be correct results on some platforms.
>
>Well, there are few exceptions ;-)
>Some are regarding platfome limitations
>A complex proxy server application written here perfectly runs
>under Windows NT and Linux JDK1.2 (green threads, grrrmbl). The
>only exception: One thread under Windows NT consumes about 1
>MB of memory each (think about 40+ clients), while using kernel
>2.2.x under Linux, it does not.
Well, the performance level between platforms is not really something
that can be addressed in Java. Just like a C compiler can not address
the fact that most RISC CPU code is larger than CISC CPU code due to
the instruction coding and the need for extra instructions (the RISC
code may well be faster but larger)
>HP/UX seems to be different, as they seem to violate the
>specification regarding variable initialisation: A declared reference
>is not definitely set to null, but to anything else.
Not all JVMs are fully to spec. Just like not all JAVA compilers
are strict :-)
>> As some old Amiga engineers know, if the developer can not tell
>> that the code was written incorrectly when they run it on their
>> system, they assume it is correct code. (The Amiga examples are
>Yes, I remember this MEMF_CHIP/MEMF_FAST problem.
>It is the same habitude which now leads to the Y2K problem: "Hey,
>who will ever use more than 2 decimals ?" converts into "Hey,
>memory is memory", "Display resolution is always 1024x768
>because I use it this way" and "My applet does not need more than
>523x268 pixels and font 10 pt font size ".
Well, those are "choices" (assumed "reasonable" limits) whereas the
Amiga case was not one of someone choosing the option of "no one
will add memory" but just not noticing that their code did something
wrong since they did not have such a problem.
Much like code on 68000 systems that had off-by-one errors for strings
on the stack but never were bitten since the next bit of data was an
address and the top byte just happened to be 0 on the address and
thus the \0 at the end of the string fit nicely until someone had
a machine with memory above the 16-meg address space (68020 CPU and up)
and suddenly code broke - not because someone made the choice but
because the error did not cause a failure until then.
I have now seen this many times in the Java world. Code that was not
"right" but somehow worked (for whatever complex reason) and then
when moved to another JVM it failed - because the code was wrong, not
because of compatibility. I think the best thing Sun could do with
the reference JVM is make it *extreemly* strick on all things and
not let anything happen to "slide by" -- But that is not an easy task.
I know, I have had to do tools like that on the Amiga back when...
>
>Oliver
>
>___________________________________________________
>Oliver Fels | e-mail:
>Neurotec Hochtechnologie GmbH | [EMAIL PROTECTED]
>Team Manager JAVA-/IT-Security |
>Friedrichshafen, Germany |
>---------------------------------------------------
>
>
>----------------------------------------------------------------------
>To UNSUBSCRIBE, email to [EMAIL PROTECTED]
>with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
Michael Sinz -- Director of Research & Development, NextBus Inc.
mailto:[EMAIL PROTECTED] --------- http://www.nextbus.com
My place on the web ---> http://www.users.fast.net/~michael_sinz
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
