We Keep Coding

What can make Java application platform dependent?

I am developing an application and wonder what can cause the app to be platform dependent. For example, using Windows path in the app make it app that runs only in Windows.

There are plenty of things that can get you there:
using JNI to make native calls to OS specific features (like: reading/writing values to the windows registry)
relying on libraries ... that do make such native calls for you
The more subtle version of the same, especially in the context of GUI programming:
relying on specific (non standard) fonts
relying on OS specific plafs
As you have written in the question:
"external" identifiers that only work in a platform specific way, like: filepaths
The good news here: all of that is rather explicit. You have to write your code in a certain way to become platform dependent.
What is much harder, but luckily less common: writing valid Java code ... that in the end, relies on specific implementation details of the underlying JVM. For example threads are mapped to the threads that your OS provides. So, theoretically, there is a chance to write java code that behaves differently on different platforms.
Also note that there are in fact various different JVM implementations that matter in todays business world. Which can again result in different behavior at runtime.
Long story short: don't worry too much. When you follow standard best practices (for example: by avoiding fully hardcoded absolute path names), then your "medium sized" project should not have platform issues. But as soon as you are talking about really large, complex applications, things can be different, in many subtle ways.

What JRE talks with

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)?

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

Is the Java Virtual Machine included with all Java softwares?

I am new to java. I know that the Java virtual machine is an abstract machine which helps to run the Java programs. So I would like to know if the JVM is included with all Java software, such as Eclipse?

Usually not. Java is used by so many programs that including it with every piece of Java software would use a lot more hard drive space than necessary, and a whole new JVM instance would have to be loaded for each one. Also, every piece of software would have to be updated whenever some security flaw is discovered. Hence, it's often installed just once, often shortly after setting up a new computer or OS installation.
Occasionally, a software package may be developed without assuming the presence of Java on a system; hence, it may include its own. Sometimes it may also need a customized JVM of some kind.
The main reason this is done is simply because Java is used by hundreds of millions, if not billions of devices. If a virtual machine or runtime is not so widespread, I can either convince my users to install it (usually an uphill battle if they're not themselves developers) or just bundle it myself.
If you're familiar with the notion of static and dynamic libraries, the same issues crop up there as well.

You may already know that,
the JVM is not one piece of software. Owners have their implementation, but other can make theirs if it satisfies various practical and contractual claims.
and the abstract specification is a Concrete implementations, which exist on many platforms and come from many vendors, are either all software or a combination of hardware and software and runtime instance hosts a single running Java application.
JVM is more to provide a way to strictly define the external behavior (subsystems, memory areas, data types, and instructions) of implementations which are described in an abstract inner architecture.
So To summarize JVM is the combination of hardware and software But not all Java packages are not included as you asked, fairly It doesn't even understand Java source code.

The reason for JVM existence

I am educating myself in the theory of programming languages and I wonder, why exactly do we need a Java Virtual Machine or any virtual machine at all for that matter? What are the fundamental reasons?
Is it solely for making it multi-platform? If so, why cannot we just have a platform independent language and different compilers for different platforms?

In their 1996 whitepaper The Java Language Environment, the Java team at Sun states the following design goals for the Java Language:
The design requirements of the Java TM programming language are driven by the nature of the computing environments in which software must be deployed.
The massive growth of the Internet and the World-Wide Web leads us to a completely new way of looking at development and distribution of software. To live in the world of electronic commerce and distribution, Java technology must enable the development of secure, high performance, and highly robust applications on multiple platforms in heterogeneous, distributed networks.
Operating on multiple platforms in heterogeneous networks invalidates the traditional schemes of binary distribution, release, upgrade, patch, and so on. To survive in this jungle, the Java programming language must be architecture neutral, portable, and dynamically adaptable.
The system that emerged to meet these needs is simple, so it can be easily programmed by most developers; familiar, so that current developers can easily learn the Java programming language; object oriented, to take advantage of modern software development methodologies and to fit into distributed client-server applications; multithreaded, for high performance in applications that need to perform multiple concurrent activities, such as multimedia; and interpreted, for maximum portability and dynamic capabilities.
A bit further down, they address the reasons for using an interpreter in greater detail:
The Java interpreter can execute Java bytecodes directly on any machine to which the interpreter and run-time system have been ported. In an interpreted platform such as Java technology-based system, the link phase of a program is simple, incremental, and lightweight. You benefit from much faster development cycles--prototyping, experimentation, and rapid development are the normal case, versus the traditional heavyweight compile, link, and test cycles.
While the Java Compiler is strict in its compile-time static checking, the language and run-time system are dynamic in their linking stages. Classes are linked only as needed. New code modules can be linked in on demand from a variety of sources, even from sources across a network. In the case of the HotJava Browser and similar applications, interactive executable code can be loaded from anywhere, which enables transparent updating of applications. The result is on-line services that constantly evolve; they can remain innovative and fresh, draw more customers, and spur the growth of electronic commerce on the Internet.

why cannot we just have a platform independent language and different compilers for different platforms?
Well. What if I write a Linear Search program (in any language..) on a 16 bit machine, compile it using a 16 - bit compiler and then try running it on a 32 - bit machine. Will it behave in the same way?.
Imagine products that have millions of lines of code. Do you think that nothing in that million line code will break because of change in machine architecture ?
Now,
Virtual Machines : These are basically software written to convert instructions into the "machine understanding / OS understanding language". They sit on top of your OS and make calls to it i.e, make the OS understand what your application wants.
JVM : is a kind of virtual Machine in which is used for Java. When you write and compile a java program, it will be in an " almost -machine independent" state. This is called as byte code. You can take it to another machine and run / interpret it.

Is it for platform portability? Yes. You already know most of the obvious features of JVM and its advantages and others have already given splendid responses.
Here I'll add the human side of the advantage Virtual Machines provide. It is primarily for ease of development and reach.
Consider C as an example of platform independent language with specific compilers for specific Operating Systems. One can code in C on Linux as well as Windows. But, you'll require an additional library header file conio.h to run your same program on a Windows system.
Now, if massive million lined source code programs and application suites were required to be recompiled on every system (with diverse hardware and software) will require them to recompile the same code over and over on each and every compiler. This may leave out some systems as possible targets, if the developers missed compiling for that system.
This actually happens in the game industry where certain games are just not compiled and build for certain systems (like most high end games are not made for Linux). The game studios are forced to compile each time for every target machine they want, like Wii, PS3, PS4, PC, XBOX etc.
It's a waste of time, effort, resources and sanity (specially when you're dealing with super massive heterogeneous file types and source codes, which take massive amounts of time to compile).
In short; It is to reduce menial repetitive recompilation of the same source code for every system, so that we programmers can focus on things worthy of our time. [Or we're just lazy ;)]
Addendum:
According to Larry Wall, the original author of the Perl programming language, there are three great virtues of a programmer; Laziness, Impatience and Hubris. Link

Java virtual machine (JVM) is a platform or a sandbox to run the byte code. Byte code has special instruction sets and operation which can only be identified by JVM.
This is the same case with any virtual machines where it expects specific set of operations.

Virtual machines are an important abstraction used to make language development and implementation easier.
A large number of languages use virtual machines of some kind to allow them to be executed. Dynamic scripting languages such as Ruby and Python are interpreted at runtime on simple virtual machine. The advantage of this is that if the interpreter can be re-compiled to run on an given environment then then language itself can be used on that environment too.
Other languages such as Java can be compiled ahead of time to bytecode which is then either interpreted or just-in-time (JIT) compiled for execution. In this model only the virtual machine itself, and not the compiler, needs to be ported to any given environment to run code there. Java used this to advantage by allowing applications to be embedded in web pages.
Even outside these more dynamic languages virtual machines are used to abstract away from the details of the underlaying hardware. For example the Low-Level Virtual Machine (llvm) compiler is engineered in such a way that it first compiles C, C++, Objective-C or whatever into instructions to run on virtual machine architecture and then translates this to real machine code. This translation can be done straight away, just as a traditional C or C++ compiler would, or at runtime using JIT compilation.
These different types of virtual machines are working at different levels of abstraction. The llvm virtual machine is, as it's name suggests, at a very low level. It abstracts the different peculiarities of CPU architectures such as how to load and store floating point numbers, if things should be passed around on the stack or in registers, and so on. Virtual machines for languages such as Python however are abstracting over operating system APIs and similar things.

Limitations of Java desktop applications?

I come from a C/C++ background and now do a lot of C# stuff.
Lately I have become interested in doing some projects in Java since playing around with the Android SDK.
I know that Java apps run in a sandbox that can limit their access to the system.
In a desktop/server application environment what kind of things are restricted?

Java applications are much in a sandbox as .NET applications are in a sandbox. They both run on their respective virtual machines, and do have some limitations as to what they can do, but for the most part, they have a good deal of access to the system, including access to native code through certain calls.
You may be thinking about Java applets, which run inside a browser, and generally will be in a security sandbox that prevents access to the system resources such as local files. (This restriction can be circumvented by specifically granting access to the system to certain applets.)
Here's a section on Security Restrictions for applets from The Java Tutorials, which includes a list of restrictions placed on applets.

Typically desktop and server application run with security disabled. However, Java and the JVM still have a robust type system, so you can't for instance cast to types that an object was not created with, cannot access freed memory and can't run off the end of buffers.

For normal desktop and server apps, the limitations are not related to the sandbox concept (though you could use it to apply very fine-grained restrictions to e.g. user-submitted code) but to the platform-independant nature of Java. Basically, OS-specific stuff and hardware access usually can't be done in pure JAVA unless specifically adressed by the API library.
Examples are:
Windows registry
Windows system tray
Bluetooth
WLAN configuration

I think the main limitation you might see, is the ability to easily use the native system API's if you needed, for example if you needed to use a user32 or kernel32 API from java I think it is possible, however it is not an easy task to do, however in C# it is fairly easy thing to do.
Also if you have some legacy C/C++ dll's you can still use them in a C# application, while in java is still hard to do especially that in the worst case when your native code api has to use pointers, you can use unsafe mode in C# application to pass pointers and allocate fixed memory on stack ... etc.
but as mentioned above Java & C# in general are very much have the same limitations especially if you are targetting being platfrom independent.