Linked by Eugenia Loli on Mon 10th Oct 2005 16:48 UTC, submitted by Shlomi Fish
General Development Shlomi Fish has written a new essay titled "When C is the Best? (Tool for the Job)". Its theme is giving several reasons (besides high speed and low memory consumption) why some code should still be written in C.
Thread beginning with comment 42816
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: C and portability
by on Mon 10th Oct 2005 22:14 UTC in reply to "RE: C and portability"

Member since:

Code portability with C means to the same compiler on a different platform. C Compiler compatibility is a different matter. Each compiler seems to have its own features and quirks which can cause the same C code to behave differently depending on which compiler it was compiled with (assuming it will compile the foreign code at all). And then of course there are platform dependencies in the actual code which are hard to avoid because nothing shields you from the system specific hardware and system specific libraries except programmer discipline.

Java has the advantage of a well specified language (unlike C), well specified run-time environment (unlike C) and well specified APIs (unlike C). The behavior of Java programs on different implementations of the run-time engine and compiled with different versions of the compiler against different implementations of APIs is well defined: anything deviating from the spec may be considered a bug. So you can can compile with the ibm compiler on AIX and test on webshpere, run on the sun jvm on solaris and jboss or use Jrockit to run it on win32 with bea weblogic. If any of this requires code changes you have encountered a bug in either the compiler, run-time environment or the API implementation. The before mentioned application servers are known to have interoperability issues due to different implementations of the huge amount of APIs they support.

Hopefully you'll understand that source portability is probably pretty damn close to perfect. Most of the portability problems of java programs from one platform to another are caused by api portability problems. For example the oracle implementation of the servlet API is on paper equivalent to the apache tomcat implentation. Indeed many applications that use this API run fine on both, but not all. The reason is that oracle did nog quite get all the semantic details right in their implementation. If you depend on the correct behavior of some of these things, you will encounter problems.

The problem isn't any different if you compare the SUN linux jvm and the win32 jvm. Indeed most of the java code of the library is identical for both platforms (no problems there). The native code it depends on however is not. A considerable part of the java API has been designed to cover up for native code portability issues (graphics, io, processes & threads). Sometimes it fails to do that properly and that's when you encounter problems porting java applications from win32 to linux or vice versa.

Reply Parent Score: 0