The original meaning of 'portable' was 'costs less to convert to a new platform than it does to rewrite for the new platform'. As languages evolved and vendor lock-ins reduced, it has since morphed to mean several things including binary compatibility and source-code compatibility.

'Platform-independent' means that there is nothing in the system or its specification that is inherently bound to a single platform.

They're related, but not the same thing.

Platform independent means, these programs can run in "nearly" all operating systems. Doesn't need to be all, but at least MS, Linux and Mac will be fine to use this word.

And, lets dig out the facts behind the word "platform independent".

NOTE: The following sentences are my opinions. If anyone read, couldn't understand the logic behind or doesn't like, just can press on buttons CTRL + W to close. I noted these because Java programmers getting seriously mad when they face this sentences. But it is always open for discussion. Check please: http://en.wikipedia.org/wiki/Platform-independent_model

Ok don't break the topic and turn back.

1. Actually and logically, any program needs a platform installer can't be considered as platform independent. For example, if I can't run Java executables without downloading and installing java runtime packages services etc... So how we can say that it is platform independent. If we can say, so nearly 80% of the windows executables are also platform independent since you can run them with virtual machines or WINE on Linux etc. And sure, if Java is platform independent, PHP, ASP, Perl, Python, Ruby etc. all scripting languages are also platform independent!? Aah, sure not... Hope you got the logic.

2. But what we can do is, we can compile our (own) softwares for many different OS's. So our software will be "cross platform"

3. What can be platform independent in real manner is (as I wrote in top, my opinions) Uncompiled assembly, C etc codes...

And when it comes to portable, this is something else. For example, the word "portable software" under "windows" operating system means;

• Doesn't use registry or Appdata folder for its files or settings.
• Works under its own folder, all files needed for it is located under it's own folder.
• Also saves it's settings to a file (ini etc) under it's own folder.

And if we go a bit further in meaning, even mustn't rely on specific hardware/software brand, model or unusual mode (like "x" brand screen card, "y" resolution, "z" release of DirectX etc.). But actually you can just ignore the last detail since this criteria is not mature yet to be accepted by all.

There are three flavors of Java: ME for mobile, SE for desktops, and EE for enterprise.

"Java is portable" refers to the SE version. It means that you can run Java bytecode on any hardware that has a compliant JVM.

It doesn't mean that ME is the same as SE is the same as EE. EE has EJBs, but SE and ME don't. That does not make them less portable.

C++ language doesn't change in all platforms.

This statement is not strictly correct. Microsoft adds extensions to their C++ that won't run elsewhere.

ANSI C++ might mean portable source code, as long as you stay away from platform-specific extensions. It does not mean portable bytecode; you may have to recompile and relink.

You want to run genetic algorithms on phones? I know that mobile devices have become pretty powerful, but I'm educated to think that GA would be a server-side functionality. Mobile devices feel more like view to me.

Platform independence in software means that you can run the same code with little or no modification on multiple platforms.

The devil is in the details:

• It depends on what you define as "the platform". In some cases, this may be a specific hardware machine configuration. In other cases, it may be a "generic PC". In other cases, it may be a virtual machine and run time environment (which is the case with Java).
• Nothing is "perfectly" platform-independent - there are always a few corner cases that can catch you out. For example, if you hard code file path separators rather than using the platform-independent File.pathSeparator in Java then your code won't work on both Windows and Linux. As a programmer, you need to watch out for these things, always using the platform-independent option where possible and test properly on different platforms if you care about portability.
• There are always some constraints on specific platforms that cannot be ignored. Examples are things like the maximum length of filenames or the available RAM on a system. No matter how much you try to be platform-independent, your code may fail if you try to run it on a platform that is too tightly constrained.
• It's important to note that some languages are platform-independent at the source code level (C/C++ is a good example) but lose platform independence once the code is compiled (since native code is platform-specific). Java retains platform independence even after code is compiled because it compiles to platform-independent bytecode (the actual conversion to native code is handled at a later time after the bytecode is loaded by the JVM).
• There are occasional bugs in language implementations that only occur on certain platforms. So even if your code is theoretically 100% portable, you still need to test it on different platforms to make sure you aren't running into any unusual bugs!

In the specific case of Java:

• Java code is platform-independent in the sense that the same Java application or algorithms (typically compiled to Java bytecode and packaged in a .jar file) will run identically on Windows and Linux.

• Java libraries (e.g. all the nice open-source toolsets) are usually platform-independent, as long as they are written in pure Java. Most libraries try to stick with pure Java in order to maintain platform independence, but there are some cases where this is not possible (e.g. if the library needs to interface directly with a special hardware or call a C/C++ library that uses native code).

• The Java platform /runtime environment is platform-independent in the sense that the same libraries (images, networking, File IO, etc.) are available and work in the same way on all platforms. This is done deliberately in order to allow applications that use these libraries to be able to run on any platform. For example, the Java libraries that access the filesystem know the fact that Windows and Linux use different filename path separators, and take account of this for you. Of course, this means that under the hood the run time environment does make use of platform-specific features, so you need a different JRE for each platform. You can see a list of some of the available platforms on the Java download site: http://www.oracle.com/technetwork/java/javase/downloads/jdk-6u26-download-400750.html

• The JVM itself (i.e. the Java Virtual Machine that is responsible for JIT compiling and running Java bytecode) is platform-independent in the sense that it is available on many platforms (everything from mainframes to mobile phones). However specific versions of the JVM are needed for each underlying platform to take account of different native instruction codes and machine capabilities (so you can't run a Linux JVM on Windows and Vice Versa). The JVM is packaged as part of the Java platform/runtime environment as above.

Overall, Java is probably about as close to true platform independence as you can get, but as you can see there is still quite a bit of platform-specific work done under the hood.

If you stick to 100% pure Java code and libraries, my experience is that you can count on Java as being "effectively" platform-independent and it generally lives up to the Write Once Run Anywhere promise. But you should still test it!!

Machine Independence

Machine independence refers to the idea of software that can be executed irrespective of the machine on which it executes. A piece of Machine dependent software might be something written to use, say assembly instructions that are specific to a certain architecture. For example, if you write a C++ application with inline assembly that relies on special processor instructions such as for example, SIMD instructions, then that peice of software is machine dependent because it has specific machine requirements - it can only work on a machine that supports that specific required SIMD instruction set.

In contrast, C# and Java compile to bytecode that is executed by a virtual machine which takes that bytecode and executes it as native code directly on the processor. In this case the virtual machine is machine dependent because it will execute against the specific hardware it is written for - for example, only a 32 bit Intel processor, or an ARM Smartphone. The Java and C# applications that run on the virtual machine however are machine independent because they care not what the underlying platform is, as long as there is a virtual machine to translate to the underlying paltform for them. That abstraction layer, the virtual machine, helps separate the application from the underlying hardware and that is the reason why those applications can be machine independent.

Portability

Portability is a separate but related concept, it is a broad term that covers a number of possibilities. A piece of software is portable simply if it can be built and executed or simply executed on more than one platform. This means that machine independent software is inherently portable as it has to be by nature.

There are broadly two facets to portability - hardware portability, and software portability. Ignoring for the moment .NET implementations such as Mono and focussing purely on Microsoft's .NET implementation it is fair to say that .NET is hardware portable because it can be executed on any hardware that supports the .NET runtime, however because Microsoft's implementation is only available on Windows and Windows descended operating systems it is fair to say that it is not particularly software portable - without Mono it cannot be executed on Mac OS X or Linux. In contrast, Java could be said to be both hardware portable and software portable because it can run on multiple operating systems like Windows, OS X, Linux hence it is software portable, and hardware portable because it can run on different hardware architectures such as ARM, x86 and x64.

Finally, there is also the question of language portability. Many would argue that although a C++ application compiled for Windows will not natively execute on Linux, it is possible to write C++ code in such a way that the same set of source code can be compiled on both Linux and Windows with no changes - this means that you can port the same application to different operating systems simply by just compiling it as is. In this respect we can say that whilst a compiled C++ application is not portable, the source code for a C++ application can be portable. This applies to a number of other languages including C.

Disclaimer

This is a somewhat simplified explanation and there are many edge cases that break these rules which make it such a complex and subjective subject - for example it is possible to write a Java application that is machine dependent if for example you use the Java native interfaces.