The core technology idea in Java

　　 Java has become a large and complex technology platform, for developers to better grasp the Java technology, in-depth understanding of the underlying technical processing details is essential. Mastering core concepts and ideas can help us extrapolate and comprehend by analogy and help us improve our understanding of the entire Java platform. Here are some of the core concepts of the Java technology platform, and the ideas that are embedded in it help us to understand Java technology more deeply. The primary task of a Java Virtual machine Java Virtual machine is to load the class file and execute the bytecode in it. A Java Virtual machine contains a class loader that can load class files from programs and APIs. Only those classes that are required for program execution in the Java API are loaded. The byte code is executed by the execution engine. In different Java virtual machines, the execution engine may be implemented very differently. In a virtual machine implemented by software, the simplest execution engine is a one-time interpretation of bytecode. Another execution engine is faster, but consumes more memory, called an "instant compiler (Just-in-time compiler)". In this case, the first executed bytecode will be compiled at cost to the machine code. The compiled native machine code is cached and can be reused when the method is called later. The third type of execution engine is the adaptive optimizer. In this approach, the virtual machine interprets the bytecode at the beginning, but monitors the activity of the running program and logs the most frequently used code snippets. While the program is running, the virtual machine compiles only the most frequently used code, and the other code continues to be byte-coded because it is not very frequent-the virtual machine continues to interpret them. An adaptive optimizer can allow the Java virtual machine to execute the optimized native code in 80%~90% time, and only need to compile 10%~20% 's performance-impacting code. When the Java virtual machine is implemented by the software on the host operating system, the Java program interacts with the host by calling the local method (native). There are two methods in Java: Java methods and local methods. Java methods are written in the Java language, compiled into bytecode files, stored in the class file. Local methods are written by other languages (such as c,c++ or assembly language) and compiled into what processor-related machine code. Local methods are saved in the dynamic-link library, and the format is proprietary to each platform. When a running Java program calls a local method, the virtual machine loads the dynamic library containing the local method and calls the method. The local method is to contact the Java program and the underlying host operating system connection method. With local methods, Java programs can access the resources of the underlying operating system directly. A native method interface (Java Native Interface, JNI)-Enables local methods to be available on a particular host system for any one JAVA platform implementation runs on. If you want to use resources on a specific host and they cannot be accessed from the Java API, you can write a platform-dependent Java program to invoke the local method. If you want to guarantee the platform independence of the program, you can only access the underlying system resources through the Java API. Architecture for Class loaders a Java application can use two kinds of loaders: the "Start (bootstrap)" class loader and the user-defined class loader. Starting the class loader (which is the only one in the system) is part of the Java Virtual Machine implementation. The startup class loader typically loads classes from a local disk in some default way, including the Java API Class (the Startup class loader is also referred to as the original class loader, the System class loader, or the default class loader). Java applications can install user-defined class loaders at run time, which can be used to load classes in a custom manner. For example, download the class file from the network. Although the Startup class loader is an essential part of the virtual machine implementation, the user-defined class loader is not, but the user-defined class loader can be written in Java, can be compiled into a class file, can be loaded by a virtual machine, and can be instantiated like other objects. Since there is a user-defined class loader, it is not necessary to know all the classes that will eventually be added to a running Java application without compiling it. A user-defined class loader makes it possible to run an extended Java application. When it runs, the application can resolve what additional classes it needs, and it can decide to use one or more user-defined class loaders to load. Because the class loader is written in Java, class loading is done with any style that can be expressed in Java code. These classes can be downloaded over the network, can be obtained from some databases, and can even be generated dynamically. Every time a class is loaded, the Java Virtual machine monitors the class to see if it is loaded by the class loader or by the user-defined class loader. When a loaded class references another class, the virtual machine loads the referenced class using the class loader that loads the first class. For example, if a virtual machine uses a particular class loader to mount the volcano class, it will use this class loader to load all classes used by the Volcano class. Because the Java virtual machine takes this way to load classes, the loaded class can see only the classes that are loaded by the same class loader by default. In this way, the architecture of Java allows multiple namespaces to be established in a single Java application. Every class loader in the runtime's Java program has its own namespace. Java applications can create as many (or as many) classes as are loaded by different class loaders in different namespaces, and they cannot access each other unless the application is shown to allow this. When writing a Java application, classes that do not load from the same source file can be divided intoare separated in different namespaces. In this way, you can use the architecture of the Java class loader to control the interplay of code loaded in any different source files, especially the ability to prevent malicious code from gaining access or destroying good-natured code. A Web browser is an example of a dynamically expanding Web browser that uses a user-defined class loader to download a class file for Java applets from the network. The Web browser uses a Java application to install the user-defined class loader. This user-defined class loader is often referred to as the Java Applet Class loader, and it knows how to request a class file from an HTTP server. Java applets can be used as an example of dynamic scaling because Java applications do not know when it will start downloading the class file from the Web browser request. It is only when the browser encounters a page with a Java applet that it decides whether or not to download the class file. A Web browser-initiated Java application typically creates a different user-defined class loader for each network address that provides a class file, so different user-defined class Loaders load class files from different sources. This allows them to be placed under different namespaces in the Java host application. Because Java applet files from different sources are placed in different namespaces, malicious Java applet Code does not directly access class files that are downloaded from elsewhere. This allows you to restrict or prevent mutual access between code from different sources. Java class files Java class files are primarily designed to make Java more suitable for networking in terms of platform independence and network mobility. Its mission in terms of platform independence is to provide Java programs with a binary form of service that is independent of the underlying host platform. This approach breaks the tradition of languages such as C or C + +, and programs written in these traditional languages are usually compiled first and then connected to a separate binary file that specifically supports specific hardware platforms and operating systems. Typically, binary executables on one platform do not work on other platforms. Java class files can be run on any hardware platform that supports Java virtual machines and binaries on the operating system. When compiling and connecting a C + + program, the executable binaries obtained can only be run on the specified hardware platform and operating system, as this binary file contains the machine language for the target processor. The Java compiler translates the instructions from the Java source file into bytecode, which is the "machine language" of the Java Virtual machine. Class files are designed to be compact so they can be delivered quickly over the network. Second, because Java programs are dynamically connected and dynamically extensible, class files can be downloaded when needed. This feature makes Java applicationsThe ability to schedule the download of class files from the network to minimize the latency of end users. The Java API Java API enables Java to adapt to network applications by supporting platform independence and security. The Java API is a collection of runtime libraries that provide a set of standard methods for accessing host system resources. When you run a Java program, the Java API class file used by the virtual machine loader's class file. All loaded class files (including those extracted from the application and from the Java API) and all loaded dynamic libraries (containing local methods) together make up the entire program running on the Java Virtual machine. Before a platform can even support Java programs, the functionality of the API must be explicitly implemented on this particular platform. To access local resources on the host, the Java API calls the local method. Because the Java API class file calls local methods, the Java program does not need to call them again. In this way, the Java API class file provides a Java program with platform-agnostic, standard interfaces for the underlying host. For Java programs, Java APIs have the same performance and predictable behavior regardless of the platform's internals. Because Java virtual machines and Java APIs are explicitly implemented on each particular host platform, Java programs themselves can become platform-independent programs. Java APIs also contribute to the Java security model. When the Java API method makes any potentially dangerous operation, such as a local disk write operation, it checks to see if authorization is granted by querying the controller. An access controller is a class that performs a stack test and determines whether an operation is allowed.

Core technical ideas in Java