Why is Java more portable than C?

Thread Starter

Spacerat

Joined Aug 3, 2015
36
Hello,
I understand that when we write a java program (the source code) we must then pass the source to another program called "interpreter" which comprises both a compiler and a JVM (java virtual machine). The job of the compiler is to convert the source code into bytecode. Byte code is NOT machine code but it is closer to assembly-like code... Bytecode is executed by the JVM which is a program that acts like an abstract/virtual hardware. The JVM does NOT convert the bytecode into machine code, correct?

Bytecode is platform independent. However, the JVM software component is platform specific: if we use Windows, we must download a Windows specific JVM, if we use a Mac a different JVM. The JMV is therefore platform dependent.

When we talk about code written in C, we say that C is not a portable language because the C compiler is platform dependent and the resulting machine code is platform dependent. More portability means "less" platform dependent. However, while the Java bytecode may be platform independent, a user still needs to have a platform dependent piece of software, the JVM, to run the bytecode. So why do we then say that Java is more portable than C?
We could write the same code in C and either compile it and share the executable with users having our same platform (OS+CPU) or directly share the C source code as long as the users have a suitable C compiler on their machine. If we wrote the same program in Java, users would still need to have a platform specific JVM. In both cases (C and Java), the users need platform specific software installed on their machine. So how is java more portable than C?

Thanks!
 

Ya’akov

Joined Jan 27, 2019
9,070
The bytecode is the executable that can be run by the JVM. While it is true the JVM is platform specific, it is a runtime element and when the code is presented to it, it does all the work of interpreting it so it will run on the particular architecture.

C, on the other hand, produces platform specific executables. While C programs can be ported to various platforms, the patches, libraries, and compiler are tools for creating a non-portable programs, not like the Java bytecode programs, which can be run—as is—on any JVM regardless of platform.

In theory, in practice Java is not as portable as it is made out to be. "Write once run everywhere" is the marketing slogan cynically reworked to "write once debug everywhere" by Java programmers.

It is, in the end, still more portable than C, which requires explicit porting while Java is, in the main, "self porting".
 

nsaspook

Joined Aug 27, 2009
13,086
Java the language is very different from a Java program IRT portability. The main portability issue I've have with Java are OS/GUI libraries. This is a nightmare when Java OS/GUI libraries are incompatible with X version of X OS.
 

BobTPH

Joined Jun 5, 2013
8,813
C is not portable at even the source code level. Here are several examples of differences between valid compliant C compilers:

1. The size of short int and long types.

2. The size, precision and representation of float and double.

3. The layout and alignment of fields within a data structure.

4. Byte order (endianness)

All of these are either strictly specified in Java, or can make no difference to the execution of the program. For example, we cannot know the order of bytes in a int in Java because we cannot use it as anything other than an int. There is no way to look at the bytes individually by address.

If a strictly correct Java executable runs without error on two different machines and produces a different result, one if the JVMs has a bug.

Of course, there can be system limits that can be exceeded, but I am talking about a program that does not hit any of those limits and runs without exceptions other than those raised by the source code itself.

The same cannot be said of C. It is trivial to write a C program that is perfectly correct C but runs differently on X86 and PIC.

Bob
 

nsaspook

Joined Aug 27, 2009
13,086
C is a high level assembler masquerading as a high level general programming language. Most of the interesting things a person would write with the C language at the embedded level would be non-portable in the hardware machine interface level details in any language across hardware platforms. The machine level non-portability of C source code is a good thing when it's really needed. What's more important IMO is using structured programming to isolate those sections of code and to create efficient data structures and interfaces to abstract those changes to code across hardware platforms. The Linux OS is a great example of this.
 

Ian0

Joined Aug 7, 2020
9,670
C is a high level assembler masquerading as a high level general programming language. Most of the interesting things a person would write with the C language at the embedded level would be non-portable in the hardware machine interface level details in any language across hardware platforms. The machine level non-portability of C source code is a good thing when it's really needed. What's more important IMO is using structured programming to isolate those sections of code and to create efficient data structures and interfaces to abstract those changes to code across hardware platforms. The Linux OS is a great example of this.
I’m so glad you said that. I find it so tiresome continually to be told that I should write microcontroller software in C because it is portable between different microcontrollers!
 

Ian Rogers

Joined Dec 12, 2012
1,136
I’m so glad you said that. I find it so tiresome continually to be told that I should write microcontroller software in C because it is portable between different microcontrollers!
Yup.... Even same brands... Pic16 to pic24 or pic32.... Even supposed same compiler....!!!! go figure.
 

drjohsmith

Joined Dec 13, 2021
852
The advertising is that Java is write once, run on any machine
this is when a Java Virtual Machine is run on the machine,

The code is written once,
and runs on the Java Virtual Machine (JVM),
the Java virtual machine, need to be designed for each machine OS,

so if there is no JVM , then JAVA can not run,

It s all a good marketing exercise,
 

nsaspook

Joined Aug 27, 2009
13,086
I’m so glad you said that. I find it so tiresome continually to be told that I should write microcontroller software in C because it is portable between different microcontrollers!
Like English. ;) It's more a matter of availability across different micro-controllers than being portable across. The marketing requirement to sell X chip is to have a C compiler, the quality and suitability of it is another departments responsibility.

The standard C language will be the same (8-bit C compilers are on a different level of existence) but implementation defined details will not. A good C compiler doesn't paper over those details, it should try to warn about possible non-portable code if you crank the warning settings to pedantic levels.
 

Ya’akov

Joined Jan 27, 2019
9,070
It can be easy to confuse portability with availability. The degree of portability, in my world, is inversely proportional to the magnitude of changes to source code.

I am willing to accept the idea of one-time work to make a platform specific environment (e.g.: compilers, runtimes, VMs, &c.) as not being figured into portability but the more I have to change the source the less "portable" the language is.

If all you have to do is compile (using configure to choose libraries is mostly OK), it's highly portable but if a person has to do the act of porting it's less and less portable depending on magnitude of that act.
 

Papabravo

Joined Feb 24, 2006
21,159
This is precisely why I believe the arguments are tenuous. On both sides there are numerous examples that support or deny the arguments for portability. It is just not a simple proposition that can be easily answered in terms we can all agree on.
 

Ya’akov

Joined Jan 27, 2019
9,070
This is precisely why I believe the arguments are tenuous. On both sides there are numerous examples that support or deny the arguments for portability. It is just not a simple proposition that can be easily answered in terms we can all agree on.
Yes, which is why I adopt a definition which relies on effort since that seems to be the promoted benefit of whatever portability is supposed to be. So, bottom line is two things:

  1. Portability is a scalar, not a boolean. Things aren't "portable", they are N portable.
  2. The magnitude of portability is inversely proportional to the effort of porting.

The idea is of portability, so far as I can work out, is only useful if the practical effect is one must do less work to use the source on various platforms. This is because the source represents the reusable work. While some parts of the toolchain may also be reusable.

I don't place a lot of weight on platform-specific environment requirements when working out portability, unless a particular platform requires a significant amount of work to allow use of source code that other platforms accept more easily.

In which case the law of portability is not a matter of the language but the target. In which case I would say the target lacks portability (since it is the issue).

Bottom line is, I agree with you that many applications of "portability" being marketing driven prevarication, are empty.
 

nsaspook

Joined Aug 27, 2009
13,086
This is precisely why I believe the arguments are tenuous. On both sides there are numerous examples that support or deny the arguments for portability. It is just not a simple proposition that can be easily answered in terms we can all agree on.
I'm a embedded programming guy so C is very portable in my domain. I always expect a programming task to map the pedantic levels of detail needed to transfer efficient to the device hardware module level C source code from device type to another even in the same processor family. Even a simple serial project like a touchscreen protocol adapter has been ported several times over the years from C18 to XC8 V3.35 on hardware from a PIC18F8722 to a PIC47Q43 on several types of touchscreens. The basic output protocol logic doesn't change but the input and signal handling are updated to use advanced hardware module capabilities and to take advantage of C99 standards to ease porting to other architectures.
 

BobTPH

Joined Jun 5, 2013
8,813
This is precisely why I believe the arguments are tenuous. On both sides there are numerous examples that support or deny the arguments for portability. It is just not a simple proposition that can be easily answered in terms we can all agree on.
That's like saying you cannot argue that circuit that fails 1 in 1,000,000 is better than a circuit that fails 1 in 10 times. After all they both fail sometimes and succeed sometimes, right?

Java IS far more transportable than C, that is a fact. If you restrict Java and C to only what is defined in the formal language definition, then Java really is 100% transportable and C is not.

Bob
 

Ian0

Joined Aug 7, 2020
9,670
I'm a embedded programming guy so C is very portable in my domain. I always expect a programming task to map the pedantic levels of detail needed to transfer efficient to the device hardware module level C source code from device type to another even in the same processor family. Even a simple serial project like a touchscreen protocol adapter has been ported several times over the years from C18 to XC8 V3.35 on hardware from a PIC18F8722 to a PIC47Q43 on several types of touchscreens. The basic output protocol logic doesn't change but the input and signal handling are updated to use advanced hardware module capabilities and to take advantage of C99 standards to ease porting to other architectures.
As a hardware designer who turned his hand to writing software when cheap microcontrollers arrived on the scene, I presume I must also count these days as an "embedded programmer", but my experience of C is entirely the opposite to yours. As more than half of my code is concerned with peripherals, then C is not at all portable, and those dreadful things called "drivers" compound the problem by being full of arcane jargon, sparsely and badly documented; the software equivalent of relying on Ebay for your component supplies. I find it far easier to refer to the manual, and simply write the appropriate value to the appropriate register. I separate my software into those bits that deal with peripherals, and those bits that don't. To move to a different processor, it is necessary to rewrite the "peripheral" part, which is sometimes most of it.

The cynic in me says that vendors promote C because it means that customers will have to buy a faster processor with more memory.
 

nsaspook

Joined Aug 27, 2009
13,086
As a hardware designer who turned his hand to writing software when cheap microcontrollers arrived on the scene, I presume I must also count these days as an "embedded programmer", but my experience of C is entirely the opposite to yours. As more than half of my code is concerned with peripherals, then C is not at all portable, and those dreadful things called "drivers" compound the problem by being full of arcane jargon, sparsely and badly documented; the software equivalent of relying on Ebay for your component supplies. I find it far easier to refer to the manual, and simply write the appropriate value to the appropriate register. I separate my software into those bits that deal with peripherals, and those bits that don't. To move to a different processor, it is necessary to rewrite the "peripheral" part, which is sometimes most of it.

The cynic in me says that vendors promote C because it means that customers will have to buy a faster processor with more memory.
It's not the opposite in most cases if the architecture of the device is similar. Often the decision to update a controller based project to a newer controller and standard board design is driven by enhanced hardware that can be a standard platform for other projects for another decade. For the touch protocol converter the driver side was rewritten to take advantage of the 8-bit PIC Q43 vector interrupts, DMA and FIFO buffers that didn't exist on the original 8-bit pic18f8722 hardware platform.

Arcane drivers and applications are my bread and water.
https://forum.allaboutcircuits.com/threads/secs-ii-host-using-a-pic18f57k42.157503/post-1367045

Hardware chip vendors promote C because customers specify a C compiler is as a requirement
 

Papabravo

Joined Feb 24, 2006
21,159
That's like saying you cannot argue that circuit that fails 1 in 1,000,000 is better than a circuit that fails 1 in 10 times. After all they both fail sometimes and succeed sometimes, right?

Java IS far more transportable than C, that is a fact. If you restrict Java and C to only what is defined in the formal language definition, then Java really is 100% transportable and C is not.

Bob
I mean the target environment is important enough to make some comparisons difficult. C is far more prevalent in the embedded world than Java. You might expect some of us to have more experience with one language as opposed to the other. I like @Yaakov 's approach to portability as a measure of effort. In the embedded world the effort to create a JVM would be immense.
 

BobTPH

Joined Jun 5, 2013
8,813
Java is not good for embedded due to the heavyweight JVM and garbage collection, which would be quite a challenge for a system requiring real time response. And the super strict typing would only get in the way for interfacing to hardware. Java, for instance, cannot map a class onto hardware registers.

It is good for writing desktop and server applications though.

There is some beauty in its design, though I hate the syntax (C derived.). I used it to write my PCB CAD package and found it excellent for that.

I haven’t tried it, but I expect my jar file would run just as well on Linux as it does on Windows.

Bob
 
Top