Develop Reference

Is Java really that cross platform?

Nowadays, I've started hearing a lot about Java. I know that its because its meant to be cross platform. But is it really?
How much can we trust the client to have JVM installed? I've quite a few books on Java in my home and really wish to read them. But every time the same question strikes me. Will the apps which I develop with Java run on most of the machines? Isn't that bad?
One way out is to use some compilers to compile Java code to native machine code. But this makes me feel, "Why use Java then?"
So, Is it worth to learn Java for cross platform? Any ideas regarding the percentage of people having JVM installed?

I would like to correct you, People dont require jre installed they require jvm.
Since Java only relies on JVM, it is platform independent (if the platform has JVM installed).
But the main thing is, That the programmer do not have to know specific knowledge of the Platform and program his application keeping one specific platform in mind. He just has to write code generate byteCode and rest part is handled by JVM, to run it on any other platform.
If you compare java with other language you will get the exact difference like in In c/c++ the source code(c program file) after the compilation using a compiler is directly converted to native machine code(which is understandable to particular machine on which u compiling the code). And hence the compiled code of c/c++ can not run on different OS.

Nowadays, I've started hearing a lot about Java. I know that its because its meant to be cross platform. But is it really?
Yes, Java is cross-platform - or, more accurately, portable. It runs on the most used architectures and platforms, often without modification, which makes it one of the most portable languages out there. (But keep in mind that you can write unportable code in almost any language and Java is no exception.)
How much can we trust the client to have JRE installed?
We can't, but that's almost never problem.
Most languages need runtimes in order to operate. The C language (and some of its derivatives, like C++) get away with the fact that the C runtime is often already installed in the OS.
For most other languages, we trust the end user to be at least willing (not even necessarily able) to install the required runtime in order to run our (and others') software. Most software these days (and this often includes C++ software) installs its required dependencies automatically in the installation script. If this isn't desirable for any reason, an alternative is to bundle (statically link) the runtime with the program when deploying it.
One way out is to use some compilers to compile Java code to native machine code. But this makes me feel, "Why use Java then?"
Not all languages that compile to native code are the same. They have different features, different tools, different libraries available, and so on.
In any case, make sure you're not confusing native compilation with static linking of any dependencies (runtime or libraries).
Even, tell me how much percent people have a JRE installed.
About 97% of enterprise computers and 89% of desktops in the USA are estimated to run Java.

The client needs a JVM, not a JRE. They will run on almost all machines. I don't have a percentage but considering that pretty much every major OS has a JVM available to them, I would say around 95% (underestimation in my opinion). Java definitely does not have a limited audience so that shouldn't stop you from using Java.
Updated in light of Andreas' comment. I was under the impression that a lot of machines came pre-installed with Java. However, the JVM can be easily downloaded so you still don't have to worry too much about whether you're going to miss out on a large audience.

I think you mixed two different concepts:
Cross-platform: A program is considered to be cross-platform if it can run on different platforms without a need to recompile it.
Q: Is Java cross-platform?
A: Of course it is.
Native app: A program that runs on the targeted platform without a need to install, download any other software. Usually the program is compiled into a machine binary. However, it may in some definitions include programs/scripts that are not machine binaries, but the target it platform is guaranteed to run them with its built-in library/software.
Q: Can Java run on any platform without JVM?
A: No. JVM is not shipped with any platform that I'm aware of, so it needs to be downloaded and installed before any Java program can run.
One way out is to use some compilers to compile Java code to native machine code. But this makes me feel, "Why use Java then?"
It all depends on what you want to achieve. If you want to create native apps, drivers, etc, then Java is definitely the wrong tool. But if you want to create an app that can run on all platform without having to recompile it and create a version for each platform, then Java can be a good option.
So, Is it worth to learn Java for cross platform? Any ideas regarding the percentage of people having JVM installed?
Again, it really depends on what you want to achieve. Java is a good option for creating cross-platform apps and it is worth learning. However, there are other options that you may want to look into, compare, and decide which one to learn. C# is a great language, and just recently, Microsoft announced its plans to make it truly cross-platform, so it is another good option.
Most PCs have JVM installed. Theodoros Chatzigiannakis provided some statistics in his answer. But you shouldn't be too worried about the numbers. Those few who don't have JVM installed, will be willing to download and install it if they like your app.
Note: In the past, you could run apps written in C# on platforms other than Windows, but you needed a .Net Framework equivalent (e.g. Mono). With Microsoft recent announcement, we should be able to use Microsoft .Net Framework itself on other platforms. We will see how this will turn out.

What is the meaning of "Java is portable"?

I'm confused about Java portability. If the Java language is portable, why is enum unknown in J2ME?
In C++, it's not important which platform or library is used. The "C++ language" doesn't change in all platforms.
My purpose is developing a Java library that just uses primitive types like int, String, or Array (something like a library for Genetic algorithms). I want to use this library in mobile and desktop applications. But it seems that enum and some other keywords do not exist in all platforms.
So I think I misunderstood the meaning of "Java portability". What does that mean?

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.

Every hardware architecture has its own somewhat unique instruction set (add ax, bx...) when you build a C++ code, the compiler turns it into a machine code specific to the system/architecture you are working on. So you have to customize and build your code for different architectures for it to work on them.
But What happens in java is, When you build it, it is compiled into a Byte code (as opposed to machine code). And the java virtual machine(JVM) interprets the Byte Code into an instruction that is understandable by the specific architecture you the program is running on.
There is JVM for every major architecture and operating system so the code you write on windows will be interpreted and run on MAC-OS or linux without any source level modification by you.
That is why Java is portable and that is where the Write Once Run Everywhere motto comes from

Java is known as a "portable language" because Java code can execute on all major platforms. What's more, once you've compiled your Java source to "byte-code" .class, those files can be used on any Java-supported platform without modification, unlike many other languages, which require compiling "machine code" for each platform, e.g. a separate ".exe" for 32-bit vs 64-bit environments.
Another meaning of "portable", used mainly in Windows environments, means that the Java run-time environment can be run from any arbitrary location in your filesystem and does not need to be "installed", that is, have important information stored in the Windows registry. This is also true for most Java applications, and enables them to be run from different drive letters, via for example an external storage device like a USB flash drive from any computer without having to install the application first.

Java provides three distinct types of portability:
Source code portability: A given Java program should produce identical results regardless of the underlying CPU, operating system, or Java compiler.
CPU architecture portability: the current Java compilers produce object code (called byte-code) for a CPU that does not yet exist. For each real CPU on which Java programs are intended to run, a Java interpreter, or virtual machine, "executes" the J-code. This non-existent CPU allows the same object code to run 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 talk to an imaginary OS and imaginary GUI. Just like the JVM presents a virtual CPU, the Java libraries present a virtual OS/GUI. Every Java implementation provides libraries implementing this virtual OS/GUI. Java programs that use these libraries to provide needed OS and GUI functionality port fairly easily.
See this link

While C and C++ language syntax and semantic are standardised, to write a truly cross-platform application is extremely difficult, unless you limit yourself to extremely basic applications.
There are a number of high level and low level reason for this - from the endianness up to how to interact with the underlying operating system (eg. opening a window).
In addition, C/C++ source code only can be considered portable, not the result of the compilation - resulting executable code and libraries are not portable, with major difference between system architectures (different CPUs for example) and Operating Systems.
Java is a fairly successful attempt to solve both of these issues:
Java does not compile code to assembly, but to a more abstract "bytecode" - a pseudo-assembly language which is "interpreted" or "recompiled on the fly" by the virtual machine (JVM) into assembly. This conversion is usually fairly efficient as bytecode is mostly quite a low level language. Some version of the ARM processor can even execute bytecode natively.
Thus, once a java app is compiled, the result can run on "any" architecture (provided a JVM is available for that machine)
Java comes bundled with a really large runtime library which provides not only an extensive implementation of the most common data structure (implemented in the JVM in the most efficent way for a particular architecture) but also provide an "hardware and software abstraction layer" - you can interact with the system in a standard way while coding, it is the JVM job to translate it into appropriate architecture and OS calls. As an example, Java provides the Swing framework, which allows you to create a GUI in a system independent way - ie, you open a window, and this is translated into Win32/MFC calls in Windows and XWin calls in Linux
Said that, there are different "types" of java:
JavaSE is the most common
JavaME is a cut down version with a limited library and not implementing the Java5.0 language changes
JavaEE for enterprise use, same as JavaSE but with a much larger runtime
Android Java, mostly compatible with JavaSE but with additional functionalities specific to android phones
However, you should be aware that the Java architecture has been designed to allow interoperability, in particularly to allow to mix libraries built for different versions or even different "types"

it means that your java program written on one machine will run on any other machine provided that machine has JVM.
refer to this link.

Portability refers to the ability to run a program on different machines. Running a given program on different machines can require different amounts of work (for example, no work whatsoever, recompiling, or making small changes to the source code). When people refer to Java applications and applets as portable, they usually mean the applications and applets run on different types of machines with no changes (such as recompilation or tweaks to the source code).

Is there a IKVM for Java? Can I run .NET assemblies on a JVM?

IKVM is an amazing beast that lets me execute Java jars in a .NET environment. That is, it's a JVM written on the .NET runtime (CLR).
Does the opposite exist? Has someone written a CLR on top of a JVM? With suitable translation and base class library implementation, we might find .NET code executes more quickly in an aggressive JIT compiler, like HotSpot, than in the CLR JIT.

The most Java programs run with IKVM (32 bit) a little faster as with Java SE. My test show 5-10% faster. That I think that MSIL code would be run slower with a HotSpot JIT.
The next problem is that MSIL has many more features as Java byte code. It can be difficult to emulate it and it consume performance.
With Mainsoft Grasshopper you have a solution that work on a Java EE server. I does not know a solution for a desktop GUI.

You can call COM or ActiveX componenets usuing JACOB (Java COM Bridge) . That what I used only time I had to call my C# code from JAVA .
Also check this link from StackOverflow How can I call .NET code from Java?
Also googled this http://michaelkimsal.com/blog/running-net-code-on-a-jvm/

Is there a particular reason Java is the only way to program Android?

I read a lot about Dalvik and Google's Android OS when it first came out. One of the things that I don't quite understand though is why Java is used. The way I understand it is this:
Java code -> Java bytecode -> Dalvik bytecode
What I don't understand is why I have yet to see anything compile to straight Dalvik code or any other front end than Java for the Dalvik VM. Is there any work being done on a straight compiler or way to work with Android without Java?
To clarify I'm looking for languages that do not compile to Java bytecode. And also I'm not concerned with dynamic languages, I've read a few questions about them already. And also I'm aware of the NDK, I'm looking for information about Dalvik-compiled languages, not actual native-compiled languages.

There is also a possiblity to write native Android applications running directly on the operating system (which is a variation of *nix). The recommended way for that is to use the Android NDK:
http://developer.android.com/sdk/ndk/index.html
There is also more "hacky" way to do that: use ARM C/C++ compiler and just write your applications like any ordinary *nix program. This fits mostly for background services without GUI, though.

What I don't understand is why I have yet to see anything compile to straight Dalvik code or any other front end than Java for the Dalvik VM.
The reason for this is basically that there is no need for a "direct-to-Dalvik" compiler, since, as you correctly point out, the existing compile chain goes via bytecode anyway.
The only reason to go directly to dalvik, would be if the language in some sense could take advantage of dex-features that's not in the bytecode. However, dex and java bytecode are extremely similar. Main difference is probably that Dalvik is register based while the JVM is stack based. Other than that, the instruction set is strikingly similar.
As you probably realized already, you can use any language that is based on the JVM, that is, that compiles to java bytecode.
Some examples:
Scala on Android tutorial
Clojure and Android with Emacs on Ubuntu

MonoDroid is a beta project that converts C#.NET code to Dalvik.
It's not quite finished, but it will open some possibilities for people that know C#, but no Java.

Everyone uses Java because that's what Android development officially supports and it's what the Android SDK is based around developing in. However, they also offer the NDK (Native Development Kit) which allows you to develop in C/C++.
See their original announcement for it here: http://android-developers.blogspot.com/2009/06/introducing-android-15-ndk-release-1.html

Is Ruby as cross-platform as Java?

You can compile a Java application and run it in any machine where the Java virtual machine is located, independently of the underlying hardware.
Since Ruby on Rails was built upon Ruby, I'm concerned if building software in Ruby in any environment is the same or not. There exists versions of Ruby for Windows, Linux and Mac at least.
So, could you do the same with a Ruby application and with a Java application? In other words, how cross-platform is Ruby?
EDIT: I mean Ruby by itself, not Ruby running in another virtual machine like in jRuby. Should I expect more cross-platform gotchas development in Ruby than in Java or are both almost the same?

Ruby is a scripting language and it is interpreted at the run time by the Ruby interpreter , The Ruby code is interpreted and converted to machine level language i.e Assembly code . Talking about the platform Independence you can run ruby code in any of the the platform like Linux ,Windows or Mac if you have platform dependent Ruby Interpreter installed.
Where as in Java , it is Compiled and converted to an intermediate byte class and this byte class is interpreted by platform dependent JVM (Java Virtual Machine ) .
In that way you can think you Ruby source file as byte class which can be run on any platform ,with one difference byte class is already compiled but ruby source file will be compiled at the Run time .

Ruby binds fairly closely to the underlying platform. This is especially the case when it comes to process/threading mechanisms, and various forms of IPC. These are more significant challenges to overcome, compared to "trivial" ones as directory seperator, and so forth. I'm pretty sure that there isn't parity between, say, the Windows Ruby runtime and the Linux Ruby runtime.
With Java, the IPC/process/thread model is the same on all platforms that runs the JVM.

Java is cross platform. Ruby is not. It very much feels like an afterthought of, "oh we have windows users, let's try and get it working".
In Java I have experienced less than 10 cross platform issues in years of heavy use. The areas that this was in, were obviously areas that would be tricky. System/File system specifics.
In ruby, I've experienced problems even when doing the first rails tutorial as have others (https://github.com/twbs/bootstrap-sass/issues/696) . I wouldn't consider ruby cross platform. The platform relies on a whole host of dependencies, which anytime one of them uses anything platform specific the whole thing breaks. i.e. see this error:
ExecJS::RuntimeError on Windows trying to follow rubytutorial
I also inherited a largish ruby project and it relied on capistrano, webkit, bcrypt and these needed a dev build kit and native builds. It did not just work. See the people having trouble here:
https://github.com/codahale/bcrypt-ruby/issues/116
It's funny, at one point they suggest someone follows a japanese post :)

As long as you don't touch hardware or threading, Ruby should work on the three major operating systems. For web development, Ruby will mostly work the same everywhere. For more advanced applications, no, because it does not offer the abstractions of the JVM (that you probably have in mind).

If nothing else, you could run JRuby, a Ruby interpreter written in Java.