I know very well that java is a portable language..and it is the byte-code that makes it portable..

However I've studied also that C is a portable language. "The programs written in C are portable i.e. programs written for one type of computer or operating system can be run on another type of computer or operating system."

Then what is the difference between C portability and Java's portability? can we say that C is also a portable language like java? I know that java portability may be in terms of different application such as mac, PC, mobile phone..and C can't be used in such cases..But my question is still as how portability is different in both language?

Please clear my confusion. Thanks in advance..

  • 4
    "The programs written in C are portable i.e. programs written for one type of computer or operating system can be run on another type of computer or operating system." really? Commented Feb 24, 2011 at 13:54
  • @Summer It's possible for code that doesn't use operating system specific libraries. But doing that is problematic from non trivial programs, especially if a GUI is involved. Commented Feb 24, 2011 at 14:03
  • @CodeInChaos - So in theory it can be done, but in practice it can't.
    – T.E.D.
    Commented Feb 24, 2011 at 14:12
  • For full programs it's hard to achieve in practice IMO. But for libraries, such as compression, audio-processing, ... which basically are pure algorithms and don't need to interact with the OS it's easy to achieve. Commented Feb 24, 2011 at 14:15
  • @CodeInChaos - I don't know whether it's your exact meaning, but a program interact with OS not only by invoking platform dependent system call or API provided by specific OS. A program begin to inter-operate with OS's the moment it is loaded into memory or even before that. Implementation of linkers and loaders employed by different operating systems decides format and portability of the executables. Commented Feb 24, 2011 at 15:24

9 Answers 9


Java is object-compatible. You compile it on one patform and the resultant class files can run on any JVM.

C is source-portable. You can take your C source code and compile it on any ISO C compiler, provided you follow the rules - that means no using undefined or implementation defined behaviour or any non-standard features.

  • 1
    And as long as you have the right libraries for C. Commented Feb 24, 2011 at 13:55
  • 5
    @Daniel: using libraries that aren't standard C is "non-standard features". Commented Feb 24, 2011 at 14:00
  • 2
    @Daniel: The libraries are part of the source. As long as they use no undefined or implementation-defined behavior, you can compile them anywhere too. Of course usually that's not the case, sometimes because IB is necessary for the functionality the library wants to provide, and (much more often) because the library authors are incompetent at writing C and don't understand what is portable/correct C... Commented Feb 24, 2011 at 14:02
  • @R..: and sometimes somewhere in between - a version that works on 85% of the platforms might in a particular case be 15% of the development effort, so the implementation-defined behavior is nice but not strictly essential functionality. Commented Feb 24, 2011 at 14:04
  • 1
    @CodeInChaos: that's a scope issue. The scope of portable C is command-line utilities that don't interact with a network or other fancy services. You can't write a portable C program with a GUI, just as you can't write a portable Java program that builds cars. C doesn't (guarantee to) have a GUI, Java doesn't (guaranteed to) have a steady supply of engines or the means to manipulate them into position. IIRC there is (or used to be) a concept of "pure Java" which is actually even more restricted in scope than standard C, it's just that when people talk "Java" they mean much more than that. Commented Feb 24, 2011 at 14:23

In C only the source code is portable, you have to recompile it on every target platform, given that a suitable C compiler exist. Also, if you access any library or operating system function it must exist on any platform where you want to run your program on.

The big deal in java is, that the language itself brings a lot of standard libarary functions with it, so you rarely need access to the operating systems api.

  • The library part is really the major difference, with standard support for graphics, threads etc. While the C standard is so vauge hardware-wise, that it barely assumes that the program will run on any form of hardware.
    – user29079
    Commented Feb 24, 2011 at 14:04

The difference is that with c you usually(unless using something like LLVM) requires a recompile on new architectures, whereas java uses the same byte-code.

But I think you shouldn't say that a language is portable, but rather that a compiler is portable. It's easy to imagine a byte-code implementation of c which directly runs on different architectures, or a directly compiling version of java which needs a recompile on new architectures.

In practice portability is mainly about libraries. In particular portable GUIs are always problematic. And the the c standard doesn't contain anything related to it. Java on the other hand has GUI toolkits which work(to a certain degree) on many platforms. But making such GUIs feel native on all platforms is hard and usually requires additional work even with cross platform toolkits(and many GUI cross platform GUI toolkits feel foreign no matter how much work you put in).

And then there are many differences in platforms like the file naming schemes, path separators, multi-threading vs forking, conventions on where to store which files,... Most of them are hard to abstract away with cross platform libraries.

  • 1
    Actually, you'd generally say that code is (or isn't) portable. You can write portable code in C, and you can write code in C that's not at all portable.
    – Caleb
    Commented Nov 6, 2011 at 19:58

With portability, it is not a matter of definition but more of degree. Some languages and environments are more portable than others.


In the days when computers were contrived, there were many processors and each had its own machine or assembly language. Worse yet, there were no standards for equipment external to the processor such as core-memory and drum memory. Thus most applications were tailored and optimized for one specific computing environment. This is when the demand for portability began.

Users of computing machinery (a.k.a. corporations) wanted more computing power and would purchase computers from various manufacturers. The Users also wanted their applications to work on the new computers; either the computer supplier would have to create a similar application or the corporation would hire people to port the application's functionality to the new computer. This became expensive.

Focus On Portability

The thinkers in computer science started working on strategies to reduce the time required to port an application running on one manufacturer's computer (e.g. Honeywell) to another (e.g. IBM). At the same time, the thinkers were becoming lazy and wanted more (machine) code written with less typing and effort. Thus began high level languages.

High level languages focused more on abstract concepts and standardization than the machine language. An application called a translator would convert the high level language to the specialized machine code. This allowed an application to be ported to another platform without minimal changes to the high level source code. In theory, for a new platform, only one translator would need to be written, then many applications (written in the high level language* could be executed on the new platform by running them through the translator. Compilers, and interpreters are specializations of a translator. Applications written in high level languages became more portable than those writing in machine language. Examples: COBOL, LISP, FORTRAN.

Portability and the Environment.

One of the keys to the languages' portability was to avoid or minimize things specific to the processor or environment that were not a part of theoretical computing. Peripherals, such as display terminals, printers and external communications were not standard. Some terminals had 132 character widths while others had 80. A new group of thinkers emerged, developing standards for the environment around the processor. They produced concepts such as ASCII, RS232, HPGL, SCSI, and etc. The peripheral manufacturers started producing products according to these standards. More people were happy. Applications became more portable.

Updating the Languages for Portability.

Some thinkers looked at the old high level languages and decided they needed either updating or reinvention to keep up with the new standards. One of these standards was graphics, which were used for GUIs. By this time, core functionality of graphics was changing less and becoming standardized. So the thinkers created new languages that would have standardized graphics capabilities (along with other features). And again, when creating new languages, other features would be added. The new languages also combined features for producing correct and robust code from the beginning (the language would reduce the possibilities for shooting one's foot). Out of this era came languages such as Java, C++, C#, Perl, Python, Ruby, etc.

These new languages included tighter specifications for portability. As long as the developer stayed within these bounds, the programs would build and execute on different platforms. The more portable languages came up with a solution to the problem of different machine languages: an intermediate executable language (i.e. byte code). The translators would produce and executable in terms of this intermediate executable language. Now applications only needed an interpreter for this intermediate executable language and they could run on a new platform.


Portability is often associated in degree rather than a hard coded definition. Standardization goes in hand with portability. The latest trend is to find ways of making an application's executable more portable across platforms, thus reducing development effort to port an application to new platforms.

When people talk about portability, feel free to question their definition as it applies to the source language or to the executable of the application.


C is a portable language, when is compared to Assembly language, which can only run in a single CPU architecture. In this sense, you can say that C is portable. Of course, for every architecture - CPU, you need a different compiler.

For Java on the other hand, you don't need a separate compiler. You need a Java runtime to be available.


Portability is a characteristic attributed to a computer program if it can be used in an operating systems other than the one in which it was created without requiring major rework.

Portability has usually meant some work when moving an application program to another operating system. Recently, the Java programming language and runtime environment has made it possible to have programs that run on any operating system that supports the Java standard (from Sun Microsystems) without any porting work. Java applets in the form of precompiled bytecode can be sent from a server program in one operating system to a client program (your Web browser) in another operating system without change.

Read more: http://wiki.answers.com/Q/What_is_portability#ixzz1EsuKJIEs


C source files can be compiled for different hardware architectures and for different operating system. The C language itself has no limitations. We can write and compile a c source file on linux, transfer the source file to a windows box and compile the same file over there with no compiler errors (assuming we have all header files and don't look at possible linking problems).

So yes, the c language is portable. But the compiler output obviously isn't, because it is machine code and only runs on one (family of) processor.


"Portable" has multiple meanings with respect to C.

In one sense, it refers to the fact that C compilers can easily be implemented on a wide range of hardware, from micros (PCs) to mainframes. The design of the language is fairly simple and compilers for it don't require lots of memory or processor power to run, at least compared to languages like Fortran, which used to be limited to larger minis and mainframes (remember, C is a product of the early 1970s, when micros were 8-bit and total system memory was measured in kilobytes).

In another sense, it means that C compiler implementations are similar enough such that source code written on one platform will compile and behave much the same way on other platforms (this is especially true with the development of the 1989 and 1999 ANSI/ISO standards). However, the C language standards try to strike a balance between portability and ease of implementation, leaving some things to the compiler implementor. Thus, not all source code is trivially portable between different systems.

Compiled C code is (typically) not byte-for-byte portable the way compiled Java code is1; C (typically) compiles to native machine code, whereas Java compiles to a byte code which is run from within the JVM. You could not take a compiled executable from an x68 system and run it on a Sparc or MIPS system, for example.

  1. I've heard that there are C compilers that generate Java byte code instead of native machine code, so in that case it's possible to write C code that winds up being byte-for-byte portable between JVMs.

C is really not all that portable. With a bit of work you can port C code, but if you ever look into the source code of some multi-platform C, you almost always find an unreadable mishmash of #ifdefs.

I'd list some languages that are more portable than C, but the list would pretty much consist of every language in existence except Assembler.

Another good question to read over is Why is it difficult to write portable C programs?

  • 1
    The intent of C portability is that it should compile and execute on another platform. The important distinction is that Java doesn't need to rebuild in order to run on another platform, whereas a C program does. Look at all the Linux distributions of code. Commented Feb 25, 2011 at 0:07
  • @Thomas Matthews - There is no "intent of C portability". C was not designed; it grew.
    – T.E.D.
    Commented Feb 25, 2011 at 11:22
  • Not only did C "grow" rather than being designed, but the committees writing specifications felt it was more important to that any new rules be consistent with the behavior of existing implementations (even obscure ones) than that they actually allow for the writing of portable code. Consequently, an expression like -0xF000 < 0xF0000000 will yield true on a 16-bit machine (unsigned comparison involving 0x1000) or a 64-bit machine (signed comparison) but false` on a 32-bit machine (unsigned comparison involving 0xFFFF1000). Even if future machines could perform 64-bit operations...
    – supercat
    Commented Aug 23, 2014 at 22:04
  • ...more efficiently than 32-bit ones, making int be 64 bits would cause huge amounts of code to become subtly buggy [for example, if a and b are type uint32_t and c is type uint64_t, the meaning of c+=(a-b); will be very different on machines where int and uint32_t are the same size, compared with those where int is larger.
    – supercat
    Commented Aug 23, 2014 at 22:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.