In-depth Java Virtual Machine (2)-Java platform independence

In-depth Java Virtual Machine (2)-Java platform independence
I. Benefits of platform independence

Java is very useful in the network environment. One of the key reasons is that the executable binary program created with Java can run on multiple platforms without any change.

Such platform independence brings many benefits. This will greatly reduce the work of the system administrator. In addition, Java platform independence is also very useful in the embedded device environment. From the developer's point of view, java can reduce the cost and time for developing and deploying applications on multiple platforms.

Java platform independence is self-evident. For our developers, we may be more interested in how Java implements methods or principles unrelated to the support platform.

Ii. How to Implement platform-independent support in Java

Java's support for platform independence is distributed throughout the Java architecture just like its support for security and network mobility, all components-languages, class files, APIs, and virtual machines-play an important role in platform-independent support.

2.1 Java Platform

The Java platform acts as a buffer between the Java program and the hardware and operating system. The Java program is compiled into a binary program running on the Java virtual machine, and it is assumed that the class file of the Java API is available at runtime. Then the virtual machine runs the program, and those APIs give the program the ability to access the underlying computer resources. No matter where the Java program is deployed, it only needs to interact with the Java platform without worrying about the underlying hardware and operating system.

2.2 Java language

The Java programming language supports platform independence of Java in the following ways: the value and behavior of its basic data types are defined by the language itself.

In languages like C/C ++, the value range of the basic data type int is determined by its placeholder width, and its placeholder width is determined by the platform. In Java, No matter what platform it runs, the int value in Java is a 32-bit binary value that indicates a signed integer, while float always follows the IEEE754 Floating Point Standard 32-bit floating point number. Similarly, this is consistent both in the Java Virtual Machine and in the class file. By ensuring the consistency of basic data types on all platforms, the Java language itself provides strong support for the non-platform nature of Java programs.

2.3. Java class file

Java class files can be created on any platform or loaded and run by Java virtual machines on any platform. Its format, including the high-priority storage conventions for multi-byte values, is strictly defined and is irrelevant to the platform where the Java Virtual Machine is located.

2.4 scalability

Java supports platform independence. One aspect is its scalability. The Java platform can be implemented on various types of computers (from embedded devices to large hosts.

Sun's changed API definition method has three basic API sets, which demonstrate the different scalability of the Java platform:

(1) Enterprise Edition (J2EE), Java Network Programming is mainly used to write some dynamic websites
(2) Standard Edition (J2SE), Core Java for short java Core basics mainly used to write some C/S architecture programs
(3) Micro version (j2s), Java mobile development is mainly used to develop java mobile apps

Iii. Factors affecting platform independence

When writing a Java program, platform independence is only an optional performance. The platform independence of Java programs depends on a variety of factors, some of which are beyond the control of developers, but most of which are controlled by developers. Basically, the platform of any Java program depends on how the author writes it.

The following factors affect the degree of independence between platforms:

3.1 Java platform deployment

Only computers or devices with the Java platform can run Java programs. Before a device runs a Java program, you must first port the Java platform to the corresponding device. In addition, the implementation interface must be installed on the corresponding device.

3.2. Java platform version

Not all standard runtime libraries are available on every Java platform. As a developer, you cannot control the Java version release cycle or deployment progress, but you can choose the Java platform on which your program depends.

3.3 Local Method

Another major factor that determines the degree of platform independence of the Java program is whether you have called the local method. When writing a Java program, the most important principle that must be followed is: do not directly or indirectly call local methods that are not part of the Java API. If you must use a local method and enable the program to run on multiple platforms, you must port the local method to all required platforms.

3.4 non-standard Runtime Library

The Java platform can be implemented by many developers. Although each developer must provide a standard Runtime Library for Java APIs, some developers may also provide additional libraries. If developers focus on platform independence, they must clearly know whether the non-standard runtime libraries used call local methods. Non-standard libraries that do not call local methods do not reduce the platform independence of the program. Otherwise, the program will be related to the platform.

3.5 dependency on virtual machines

When writing a platform-independent Java program, you must follow two principles. These two principles are related to some parts of the Java Virtual Machine. Some parts of the Java Virtual Machine can be implemented by different development and commercialization methods. The two principles are:
1) do not rely on finalization to ensure program correctness;
2) do not rely on thread prioritization to ensure program correctness.

These two principles can prevent the adverse effects of garbage collection and thread changes in different implementations in Java Virtual Machine specifications.

All Java virtual machines must have garbage collection heaps, but different implementations may use different garbage collection technologies. This flexibility in the Java Virtual Machine specification means that objects in a specific Java program may be garbage collected at different times in different virtual machines. This also means that the finalizer method that is run by the garbage collector before the object is released may run at different times on different virtual machines. If a termination method is used to release limited memory resources, such as file handles, the program may run on some virtual machine implementations, but not on other implementations. In some implementations, the program may have exhausted limited resources before the Garbage Collector gets the chance to call the end Method for releasing resources.

In the implementation of different Java virtual machines, another change is related to the thread priority. Java Virtual Machine specifications only ensure that all running threads with the highest priority in the program will get some CPU time. This specification also ensures that lower-priority threads run when high-priority threads are blocked. However, when a thread with a higher priority is not blocked, the running of a thread with a lower priority is not prohibited. In the implementation of some virtual machines, even if the threads with higher priority are not blocked, those threads with lower priority may first obtain the CPU time. If your program depends on the correctness of this behavior, it will be able to run normally on some virtual machines, but not on some implementations. To ensure that the platform of multi-threaded Java programs is independent, you must rely on sychronization instead of priority to coordinate actions between threads.

3.6 Dependency on user interfaces

Another major change between the implementations of different Java platforms is the user interface. When writing independent Java programs on the platform, the user interface is more difficult. You must use these basic libraries to create an interface to make it easier for users on different platforms. This is often not a simple task.
Although AWT and Swing libraries make it easier to create user interfaces running on different platforms, however, they do not necessarily make the interface design more convenient, and the interface must make users on different platforms feel happy to use.

3.7. Java platform implementation bug

Another change between the different implementations of the Java platform is the bug. Although Sun has developed a set of comprehensive test standards, the Java platform must pass this standard test. However, some implementations may still contain bugs during release. You can only test to prevent this possibility. If it does, you must try to find a way to bypass it.

3.8 Test

Because there may be differences between Java platform implementations, depending on Java programs written on some specific platforms, there may be bugs in the implementation of any specific platform. Therefore, we should try to test the Java program on all platforms that we want to run. In practice, testing your Java program on different hosts running programs and different Java platform implementations is a key factor that is unrelated to the program platform.

In addition to the above content, in deep Java Virtual Machine version 2, there are seven platform-independent steps, platform-independent policies, platform-independent and network mobile objects.

For bloggers, it is sufficient to understand how Java achieves platform-independent support and the content that affects platform-independent factors. If you want to learn more, you can download deep Java Virtual Machine version 2.

Reference books: go deep into Java Virtual Machine Version 2