What JRE talks with

Question

I have little to no knowledge of Java as a whole. I also tried to find that information by myself, without success though. This is why I decided to ask it here despite the negative attitude I am expecting afterwards. So here it is:

Does the JVM have access to the memory registries, or it uses(calls) the underlying system(the operation system or BIOS ) interfaces?

I am asking this question for basic knowledge of what JVM depends on. - On the operation system? - On the hardware platform (processor)? - Or may be on both?

I am considering this issue, because I have a kit with processor Allwinner A20 running Linux Debian. I want to run a code (java code if possible) that manipulates the processor's GPIOs.

I have read that Java has ports to many platforms. What do they mean by platform - operation system or hardware(CPUs)?

Answer 1

This lack of clarity is not uncommon and dates back to the early days of Java, nearly 20 years ago now.

The term Java can refer to either of two distinct though tightly related things:

• a language, object-oriented in nature, compilers for which produce not CPU-specific machine code but an abstract machine code
• a program, or "runtime", that is hardware- and OS-specific, whose job it is to execute the abstract machine code on a particular hardware/OS platform combination

Since JRE was mentioned- the "JRE" artifact for a particular hardware/OS platform is largely just the second thing, while the "JDK" artifact for a particular hardware/OS platform is both things;

Java-the-language very deliberately does not have any direct facilities for utilizing OS/hardware specific resources. Everything is abstracted by classes, and while many hardware/OS objects- like Threads and Files- have abstract representations in Java-the-language's object oriented class library, many others- process IDs, for instance- do not.

Java-the-runtime is an extremely sophisticated piece of machinery that can turn abstract machine instructions produced by Java-the-language's compiler into executable code, execution of which can rival native, hand-tuned implementations in performance, at the cost of some efficiency for automated memory management- and can do so on different OS/hardware platforms from the same source code written in Java-the-language.

Although Java-the-language does not have facilities to talk directly to hardware- that is, to the interface to the hardware exposed by the operating system- Java-the-runtime has the ability to load hardware/OS specific native libraries that are authored in accordance with specific requirements and which can expose an object-oriented interface to the specific hardware/OS facility to programs written in Java-the-language.

There is of course more subtlety in this world- there are fundamental differences between the two dominant providers- Oracle, formerly Sun, which produces a toolchain for desktop and server platforms, and Google which produces a toolchain for Android-based hardware.

The same source code has some degree of compatibility between the two toolchains, though the abstract machine code produced from that source code by one toolchain is not compatible with the other.

That said, it is the case that if you have a specific piece of hardware, and you want to talk to it from Java-the-language, you need:

• an operating system that runs on the hardware
• a Java-the-runtime for that specific operating system/hardware platform- whether based on Oracle/Sun's work, or Google's
• a native library that adheres to the expectations Java-the-runtime has, that provides a suitable interface to the hardware for Java-the-language