What is portability? How is java more portable than other languages?

I wonder how Java is more portable than C, C ++ and .NET and any other language. I read many times that Java is ported thanks to the interpreter and the JVM, but the JVM just hides the architectural differences in the hardware, right? We still need different JVMs for different machine architectures. What am I missing here? Therefore, if someone writes an abstraction layer for C for the most common architectures, let’s say CVM, then any C program will work on those architectures when CVM is installed, right?

What is this portability? Can .NET be called portable?

+24
java c programming-languages portability
Oct 13 2018-10-10
source share
11 answers

Portability is not black and white, yes or no. Portability is how easy it is to take a program and run it on all platforms that you should take care of.

There are several things that affect this. One is the language itself. The Java language specification usually leaves much less “implementation”. For example, "i = i ++" is undefined in C and C ++, but has a specific meaning in Java. More practical, types of type "int" have a certain size in Java (for example: int is always 32 bits), while in C and C ++ the size varies depending on the platform and the compiler. Only these differences do not prevent you from writing portable code in C and C ++, but you need to be much more diligent.

Others are libraries. Java has a bunch of standard libraries that C and C ++ do not have. For example, streaming, network, and graphics libraries. Libraries of this kind exist for C and C ++, but they are not part of the standard, and the corresponding libraries can vary widely from platform to platform.

Finally, there is the whole question of whether it is possible to simply take the executable file and drop it on another platform and make it work there. This usually works with Java, assuming there is a JVM for the target platform. (and there is a JVM for many / most platforms that people care about) This is usually not the case with C and C ++. Usually you will need at least a recompilation, and it is assumed that you have already taken care of the previous two points.

Yes, if "CVM" exists for several platforms, this will make C and C ++ more portable - sort of. You still need to write your C code in a portable way (for example: not assuming anything about int size, other than what the standard says), or you should write CVM (provided that it has made a uniform decision for all these things on all target platforms ) You also need to refuse to use non-standard libraries (no networks, streaming or a graphical interface) or write to CVM libraries for these purposes. So, we really are not talking about making C and C ++ more portable, but a special CVM-C / C ++ that is portable.

Again, portability is not black and white. Even Java may still be incompatible. GUI libraries (especially AWTs) were notorious for being incompatible with behavior, and anything related to threads can behave differently if you get sloppy. In general, however, it is much easier to take a non-trivial Java program written on one platform and run it on another than it should do the same with a program written in C or C ++.

+36
Oct 13 2018-10-10
source share

As others have said, portability is a somewhat fuzzy concept. From a certain point of view, C is actually more portable than Java. C makes very few assumptions about basic hardware. It does not even assume that the byte is 8 bits, or that negative numbers should be represented using two additions. Theoretically, as long as you have a Von Neumann based machine and compiler, you can go with C.

In fact, the Hello world program written in C will run on many other platforms than the Hello world program written in Java. You could probably get the exact same hello world program that runs on PDP-11 and iPhone.

However, the reality is that most real-world programs do a lot more than the output of "Hello world". Java has a reputation for being more portable than C, because in practice it takes a lot more effort to port real C programs to different platforms than in real Java programs.

This is because C is ANSI-C, which is a general-purpose language with bare bones. It does not support network programming, threads, or GUI development. Therefore, as soon as you write a program that includes any of these things, you should abandon a less portable extension in C, such as Win32 or POSIX or something else.

But with the help of Java, network programming, streaming, and GUI tools are language-defined and built into every VM implementation.

However, I think that many programmers also underestimate the progress of modern C / C ++ regarding portability these days. POSIX is essential for providing cross-platform streaming, and when it comes to C ++, Boost provides network and streaming libraries that are basically as portable as everyone in Java. These libraries have some platform-specific quirks, but also Java.

Essentially, Java relies on every platform that has a virtual machine implementation that will interpret byte-code in a predictable way, while C / C ++ uses libraries that contain platform-specific code using a preprocessor ( #ifdef s). Both strategies allow cross-platform streaming processing, networking and GUI development. It's just that Java has made faster progress than C / C ++ when it comes to portability. The Java language specification was associated with streams, networks, and the graphical interface from almost the first day, while the Boost network library appeared only in 2005, and only in 2011 with C ++ 11 standard portable streaming processing was included in C ++.

+20
Oct. 16 '10 at 0:50
source share

When you write a Java program, it runs on all platforms for which the JVM is written for them - Windows, Linux, MacOS, etc.

If you are writing a program in C ++, you will have to compile it specifically for each platform.

Now they say that the Java motto "write once, run everywhere" is a myth. This is not entirely true for desktop applications that require interaction with many of their own resources, but each JavaEE application can be run on any platform. I am currently working on windows, and other colleagues are working on Linux - without any problems.

(Another thing related to portability is JavaEE (enterprise edition). It is said that applications written using JavaEE technology run on any JavaEE certified application server. However, this is not the case, at least until JavaEE6. ( See . here ))

+7
Oct 13 2018-10-10
source share

Portability is a measure in order to make a program work in a different environment than where it originated.

Now you can discuss whether the JVM for Linux is a different environment than for Windows (I would say yes), but the fact remains: in many cases when working with you there is not enough effort to avoid a few errors.

The CVM you are talking about is a lot that POSIX libraries and runtime libraries are trying to provide, however there are big differences in implementation that make it difficult to overcome obstacles. Of course, in the case of Microsoft and Apple, they are probably intentionally so that the developers do not release products on competing platforms.

On the .net front, if you can stick to what mono provides with the open source .Net, you will use about the same portability as Java, but since mono is significantly behind Windows versions, this is not a popular choice. I do not know how popular this is for server development, where I can imagine that this is not a problem.

+5
Oct 13 2018-10-10
source share

Java is portable from a developer's point of view: code written in Java can be executed in any environment without the need for recompilation. C is not portable, because in many cases it is not only tied to a specific OS, but also always tied to a specific hardware architecture after compiling it. The same is true for C ++ .. Net is more portable than C / C ++, since it also relies on a virtual machine and therefore is not tied to a specific hardware architecture at compile time, but is limited to Windows machines (officially).

You are right, the JVM is platform specific (it should be!), But when you say that Java is portable, you are talking about it from the developer's point of view, and standard Java developers do not write JVMs, they use this :-).

Edit @ Raze2Dust To solve your question. Yes you can. In fact, you can make the Java platform specific by writing a compiler that will generate machine code, not byte code. But, as some other comments show, why are you doing this? You will need to create an interpreter that matches the compiled code for operations in the same way that the JVM works. So the long and short of them, of course, you could definitely, but why would you?

+3
Oct 13 2018-10-10
source share

You ask if it is possible to write "C VM". Not really. "Java" is a big term used by Sun to mean many things, including a programming language and a virtual machine. "C" is just a programming language: before the compiler and the OS and processor, to determine in what format the resulting binary should be.

C is sometimes said to be portable since it does not indicate the runtime. The people who wrote your compiler were able to choose the things that make sense for this platform. The disadvantage is that C is quite low-level, and the platforms are different enough that for C programs it is very good to work on one system, and not on another.

If you combine C with a specific ABI, you can define a virtual machine for it similar to the JVM. For example, there are several such things, for example:

  • The Intel Binary Compatibility Specification is an example of such an ABI (which almost no one uses today)
  • "Microsoft Windows" can also be such an ABI (albeit huge and unsaid), for which Wine is one virtual machine in which programs written for it are running.
  • "MS-DOS" for which dosemu is a single VM
  • "Linux" is one of the most popular today, whose programs can be run by Linux, NetBSD , or FreeBSD themselves.
  • "PA-RISC" for which the HP Dynamo was a JIT-like VM

All of these virtual machines are actually a real machine - no one, AFAIK, ever made a C virtual machine that was purely virtual. This is not surprising since C was designed to make efficient use of hardware, so you could also run it on the same system. As HP has shown, you can still make JIT to run code more efficiently, even on the same platform.

+2
Oct. 13 2018-10-10
source share

Java provides three different types of portability:

Portability of the source code:. This Java program should give identical results regardless of the main processor, operating system or Java compiler.

Portability of the processor architecture: current Java compilers produce object code (called byte code) for a CPU that does not yet exist. For each real processor on which Java programs are intended, the Java interpreter or virtual machine "executes" the J code. This non-existent CPU allows you to use the same object code on any CPU for which a Java interpreter exists.

OS / GUI Portability:. Java solves this problem by providing a set of library functions (contained in Java-supplied libraries such as awt, util, and lang) that speak to the imaginary OS and imaginary GUIs. Just as the JVM represents a virtual processor, Java libraries represent a virtual OS / graphical interface. Each Java implementation provides libraries that implement this virtual OS / GUI. Java programs that use these libraries to provide the required functional port of the OS and graphical interface are pretty easy.

See link

+2
May 31 '16 at 9:15
source share

You need a JVM for different architectures, but, of course, your Java programs run on this JVM. Therefore, when you have a JVM for an architecture, your Java programs are available for that architecture.

So, I can write a program in Java, compile it into Java bytecode (which is an architectural agnostic), which means that I can run it on any JVM in any architecture. The JVM abstracts the core architecture, and my program runs in a virtual machine.

+1
Oct 13 2018-10-10
source share

The idea is that Java is portable (or rather, compiled bytecode portable). You are right that each virtual machine requires a specific implementation for a given hardware profile. However, once this is done, all java bytecodes will work on this platform. You write java / bytecode once and it runs on any JVM.

.NET is very similar, but with a much lesser emphasis on principle. The CLR is similar to the JVM and has its own bytecode. Mono exists on * nix, but you are correct that it is not "official".

+1
Oct 13 2018-10-10
source share

Portability, or as indicated on Wikipedia, “Software Portability” is the ability to reuse the same software (code) in multiple environments (OS). Java JVM is a JVM that can be run on any operating systems that have been developed for: Windows, Linux, Mac OS, etc.

In .NET, you can port your software to different platforms. From Wikipedia :

The design of the .NET Framework allows theoretically to be an agnostic platform and, therefore, cross-platform compatible. That is, the program is written to use the framework without changes on any type of system for which it is implemented.

And since Microsoft never implemented the .NET environment outside of Windows and did not notice that .NET is an agnostic of the platform, Mono made it possible to run .NET applications and compile code to work on Linux.

For languages ​​such as C ++, Pascal, etc., you will need to go to each OS and build it on this platform in order to run it on this platform. The exe file on Windows does not match the .so in linux (machine code), since both use different libraries to talk to the kernel, and each OS has its own kernel.

+1
Oct 13 2018-10-10
source share

WORE - Write Once Run Everywhere

This is actually limited to JVM platforms, but it covers most of the platforms you would like to deploy to. This is almost halfway between the interpreted language and the compiled language, benefiting from both.

0
Oct 13 2018-10-10
source share



All Articles