Develop Reference

Languages that compile to Java Bytecode and can run on the JVM

I am an embedded programmer and working with an embedded JVM.
This enables running Java files on constrained devices.
These Java files are first compiled to bytecode into .class files which are then further optimized and uploaded to the device which has a micro JVM to run the optimized bytecode.
The micro JVM does not support all features, e.g., no reflection.
The main benefit is obvious: this allows programming in Java for constrained devices.
However, I was thinking that plenty of languages compile to bytecode, some are listed https://en.wikipedia.org/wiki/Java_bytecode.
So in theory these languages could also be used to program.
I'd like to obtain a list of common languages that compile down to bytecode and was wondering if you could help.
For example, Python has special implementations that reduce to Java Bytecode, if I'm not mistaken, and stuff like C to Java virtual machine compilers also exist.
So what languages would you think are logical to try and run on the devices? Any pointers on how to or similar experiences?
Also, I'm not clear what the difference is from reading Wikipedia between (Python) bytecode and Java bytecode, could anybody help explain that?

I'm agree with you about the overall idea and it would be nice to develop an embedded application using any language that can run on a JVM. But there are some practical issues that you should consider and I think that's why none of major vendors or open source initiatives have any active/serious project on this (as far as I know).
As you mentioned, a JVM implementations that can run on embedded devices, each have their own constraints and limitations. The most obvious one is that some packages may not be available at runtime. In order to apply such a constraint, you should either control it in the compile process or have a toolchain (sort of an SDK) which accepts the bytecode and checks such constraints.
This situation would be worth when a developer tries to use a third party library that is available for that specific language. It's not easy to guess if a library is safe for use against such a framework or not.
One great facility for developers would be to have their IDE check such issues on the fly (something like inspection in IntelliJ Idea). This makes it much more smoother to move toward using such a solution. But again the problem is that for each such languages there need to be a specific plugin compatible with their own syntax.
Also some of JVM languages that are actually implementation of an existing language (e.g. Jython or JRuby) are most of the time out of sync with the original language in case of supporting libraries/syntax changes of that language.
Anyway, I think in order to have a list of JVM languages you could easily find them on Wikipedia. Maybe you mean those who may worth considering in this regard by having a large community and tools support. In my opinion, you should focus on the following JVM languages as those who may worth to include in your final list:
Groovy
Kotlin
Scala
These are all pure JVM languages and are only using different syntax than Java.
Regarding the topic in general, I should say that when you search for embedded JVM implementations, you'll notice that it's also a fairly academic concepts and they're so many publications in this topics regarding the overall architecture, threading support, toolchain, error handling, memory management, etc. This means that you should have a very great experiences/background on both embedded systems and programming language concepts and implementation to be able to devise a proper architecture for such a platform.
About your last question regarding the difference between Python bytecode and Java bytecode (if I understand your question correctly), these are both conceptually the same but each has its own syntax and constraints. The bytecode concept refers to the piece of software that is the output of the compiler and is the platform independent representation of the original code and can be run/interpreted at runtime by another software component which is the virtual machine. In Java world, this software is called the Java Virtual Machine (JVM). I'm from the Java world so I don't know what it's called in Python vocabulary but it should be something similar (e.g. Python virtual machine).
I think due to the complexity of developing such a toolchain and also considering the unprecedented development of new IoT and SoC devices, many of them capable of running a more higher level operating systems, maybe in a long run most developers prefer to develop for a more high end devices using more high level APIs and SDKs. Who knows! In that case, we would have a same situation that we're in today for PCs. Languages like C and Assembly are still in use, but they have their own domain of applications. I mean throughout the time, layers of abstraction are being added on top of the previous one. The same thing can happen for embedded devices.

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.

How does Java differ on different platforms?

I am currently in high school. I was recently browsing the internet looking for what employees in the software industry usually want and what the job requirements are like.
I came accros a job description and one of the requirement is:
Strong, object-oriented design and coding skills (C/C++ and/or Java
preferably on a UNIX or Linux platform)
Note the last part: Java preferably on a UNIX or Linux platform.
I don't understand this. Isn't Java run inside a virtual environment/machine? Why would it matter what OS it is running on since Java cannot directly interact with the OS?

A developer job description may require experience with some OS for several reasons:
First, as you noticed already, there are languages that talk directly to the OS and the code needs to be aware of the underlying OS (like C/C++, which are listed in your job description).
Secondly, even if the programming language abstracts away anything that's OS-specific from you (including the file-system / path separators), you are still going to deploy / configure / run / monitor your applications on top of some OS and you need to know (at least) the basics in order to do that.
For a Java job description, If UNIX/Linux "is a plus", it usually means you're going to run your code on a UNIX/Linux system and you should know how to start a process (your own java app or some application server), how to deploy an application in a container, how to read log files and so on...

While Java the language runs on a virtual machine, the Java library must abstract access to facilities available on the host platform. Ideally, these abstractions are cross-platform, but the devil is in the details—hence the preference for experience on a particular target platform.

Develop once debug everywhere
While conceptually it shouldn't make any difference on what target platform the java code is executed on unfortunately in practice it isn't always that simple but a rather tedious task to get the code running on any platform.
Beginning from easy to circumvent mistakes e.g. using / or \ instead of java.io.File.separatorChar or : / ; instead of or java.io.File.pathSeparatorChar
there are most often problems including methods implemented in native code that often aren't that compatible across different platforms.
It might be even possible your employer is looking for someone to implement native java methods using JNI.

First, you're right in that Java runs inside of a virtual machine - it doesn't directly expose the inner workings of the system to you. However, that doesn't mean that each system doesn't differ in some way under the covers - different flavors of operating systems have different kernels, different ways they think about scheduling, different ways to handle threading, and different interrupt chains (Linux has quite a few signals, whereas Windows has a handful).
As far as Java (the language) is concerned, it runs the same everywhere. How it's actually accomplished is dependent on the native JVM that it's running on.
For this job posting, though, I wouldn't read too much into the UNIX/Linux portion. This is more or less gauging how comfortable someone would be working in a UNIX or Linux environment while programming Java. The majority of IDEs available for Java are cross-platform, but that shop may be using Mac or some flavor of *nix (RHEL, Debian, Ubuntu, etc). It'd also be important to make use of the command line/shell script, since a lot of the convenience of working with UNIX/Linux is on the command line.
Not every shop uses Windows machines to develop on. Just a heads-up.

Java does not differ on different platforms. That is the most highlighting feature of Java ( portability ). The JVM abstracts the underlying platform.
However, platform matters when it comes to a software development, which involves not just the coding part. Mostly in industries, devs work on Linux platform by logging into a terminal. You don't get a GUI as in Windows and a good IDE like NetBeans. So in that case, you should know how to compile and run a java program from terminal.
Example, In linux, In order to create a package, you create a directory ( folder ), say myJava/. You go into it (cd myJava) and write the SomeThing.java file and compile using javac SomeThing.java and you get a SomeThing.class file ( inside myJava ). Now in order to execute this, you need to use the java command. Prior using it, you need to move to the parent directory containing this package. Then execute as java myJava.SomeThing. You wouldn't be knowing this unless you play around in Linux platform. Other things like setting up the classpath etc are also matters of concern

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.

building a system in Java and assembly language that runs on "bare metal"

Alright everyone,
Let's say i wanted to make a system that used only assembly and java, my question would be, as long as i included all of the jvm folders, classes, jars, etc.. java should still function effectively?
i understand there are those things that are compiled platform specifically but this is why i am asking, is it possible, using assembly to replicate all of the .exe, or other executable files that java has included into a pure assembly/java system?

If you are asking whether it is possible to build a system in Java and assembly language that runs on "bare metal", the answer is yes. There are a couple of current examples:
JavaOS is targeted primarily at the embedded systems domain. (Sun consider SunOS to be a "legacy" product line these days.)
JNode aims are broader, and encompass embedded systems, desktop systems, servers and cloud computing.
Be aware that building a system of this kind is a multi-year, multi-person project requiring deep understanding of virtual machine internals, compilers, garbage collectors, hardware architectures, device driver writing and so on.
If you are asking about something else, please be more explicit.
EDIT: responding to the OP's followup question:
It is not practical to use the Java and other "exe" files per se. They require a fully fledged operating system underneath them; e.g. Windows, Linux, whatever. If you had access to the source code, you could conceivably rewrite as required to make them run on "bare metal", but that would entail significant architectural changes, especially if you want to write device drivers, etc in Java. (Besides, the core of Sun's JRE is implemented in C++ ... ).
You cannot directly use the existing Java class library JAR files, because they include a significant amount of platform specific code. However, you can build your own Java class library JARs from an existing open-source version of the Java class libraries (e.g. the OpenJDK 6.0 J2SE libraries). You deal with the platform specific code by providing your own versions as native libraries or (as JNode does) as Java classes.

If I understand your question correctly, you mean something like JavaOS. Sure, its possible to implement the JVM raw on the hardware, not sure why you would, though. And if you did, why you wouldn't use C instead of Assembly for most of the work.

Its theoretically possible to implement the jvm in a whole other language. The best example I can think of is Python/Jpython where there is the original C implementation and a pure Java implementation of the language.
The main argumant against this is -- its a ton of work for not much benefit.
The official Sun jvm and supporting jni libraries are written mostly in C, you would need to provide native assembler implementations for most of the C POSIX APIs at the very least.
Also the original design goal of C was 'a portable assembly language' and to a large extent it still meets these goals. C produces efficient machine code and most C compilers will let code machine instructions inline with the C code.
Another benefit of C is the number of cross compilers available, you dont need to run the development environment on tHe target architecture, you can deveop and unit test on your favourite paltform/IDE, when you are ready you can then export your executables to the target platform.

Jikes RVM and Sun's Maxine provide a JVM implementation with little (of the order of 1 kloc) native code. However, both VMs require an OS and are only research implementations. The process of creating a stream of octets that form machine code, is obviously achievable in Java.

Have a look at JNode. They have been working on this for years.
http://www.jnode.org/