chap01.html

Inside the java virtualMachine,深入研究java虚拟机

<P>One aspect of security is simple program robustness. Java韘 architecture guarantees a certain level of program robustness by preventing certain types of pernicious bugs, such as memory corruption, from ever occurring in Java programs. This establishes trust that downloaded code will not inadvertently (or intentionally) crash, but it also has an important benefit unrelated to networks: it makes programmers more productive. Because Java prevents many types of bugs from ever occurring, Java programmers need not spend time trying to find and fix them.</P>
<P>One opportunity created by an omnipresent network is online software distribution. Java takes advantage of this opportunity by enabling the transmission of binary code in small pieces across networks. This capability can make Java programs easier and cheaper to deliver than programs that are not network-mobile. It can also simplify version control. Because the most recent version of a Java program can be delivered on-demand across a network, you needn韙 worry about what version your end-users are running. They will always get the most recent version each time they use your program.</P>
<P>Platform independence, security, and network-mobility--these three facets of Java韘 architecture work together to make Java suitable for the emerging networked computing environment. Because Java programs are platform independent, network-delivery of software is more practical. The same version of a program can be delivered to all the computers and devices the network interconnects. Java韘 built-in security framework also helps make network-delivery of software more practical. By reducing risk, the security framework helps to build trust in a new paradigm of network-mobile code.</P>
<H3><EM><P>The Architecture</P>
</EM></H3><P>Java韘 architecture arises out of four distinct but interrelated technologies, each of which is defined by a separate specification from Sun Microsystems:</P>
<UL><LI> the Java programming language
<LI> the Java class file format
<LI> the Java Application Programming Interface
<LI> the Java Virtual Machine</UL>
<P>When you write and run a Java program, you are tapping the power of these four technologies. You express the program in source files written in the Java programming language, compile the source to Java class files, and run the class files on a Java Virtual Machine. When you write your program, you access system resources (such as I/O, for example) by calling methods in the classes that implement the Java Application Programming Interface, or Java API. As your program runs, it fulfills your program韘 Java API calls by invoking methods in class files that implement the Java API. You can see the relationship between these four parts in Figure 1-1.</P>
<P><IMG SRC="fig1-1.gif" tppabs="http://www.pbg.mcgraw-hill.com/betabooks/venners/images/fig1-1.gif" ALT="Figure 1-1"></P>

<P>Together, the Java Virtual Machine and Java API form a &quot;platform&quot; for which all Java programs are compiled. In addition to being called the <I>Java runtime system</I>, the combination of the Java Virtual Machine and Java API is called the <I>Java Platform</I>. Java programs can run on many different kinds of computers because the Java Platform can itself be implemented in software. As you can see in Figure 1-2, a Java program can run anywhere the Java Platform is present.</P>
<P><IMG SRC="fig1-2.gif" tppabs="http://www.pbg.mcgraw-hill.com/betabooks/venners/images/fig1-2.gif" ALT="Figure 1-2"></P>

<H3><P>The Java Virtual Machine</P>
</H3><P>At the heart of Java韘 network-orientation is the Java Virtual Machine, which supports all three prongs of Java韘 network-oriented architecture: platform independence, security, and network-mobility.</P>
<P>The Java Virtual Machine is an abstract computer. Its specification defines certain features every Java Virtual Machine must have, but leaves many choices to the designers of each implementation. For example, although all Java Virtual Machines must be able to execute Java bytecodes, they may use any technique to execute them. Also, the specification is flexible enough to allow a Java Virtual Machine to be implemented either completely in software or to varying degrees in hardware. The flexible nature of the Java Virtual Machine韘 specification enables it to be implemented on a wide variety of computers and devices.</P>
<P>A Java Virtual Machine韘 main job is to load class files and execute the bytecodes they contain. As you can see in Figure 1-3, the Java Virtual Machine contains a <I>class loader</I>, which loads class files from both the program and the Java API. Only those class files from the Java API that are actually needed by a running program are loaded into the virtual machine. The bytecodes are executed in an <I>execution engine</I>, which is one part of the virtual machine that can vary in different implementations. On a Java Virtual Machine implemented in software, the simplest kind of execution engine just interprets the bytecodes one at a time. Another kind of execution engine, one that is faster but requires more memory, is a <I>just-in-time compiler</I>. In this scheme, the bytecodes of a method are compiled to native machine code the first time the method is invoked. The native machine code for the method is then cached, so it can be re-used the next time that same method is invoked. On a Java Virtual Machine built on top of a chip that executes Java bytecodes natively, the execution engine is actually embedded in the chip.</P>
<P><IMG SRC="fig1-3.gif" tppabs="http://www.pbg.mcgraw-hill.com/betabooks/venners/images/fig1-3.gif" ALT="Figure 1-3"></P>

<P>Sometimes the Java Virtual Machine is called the <I>Java interpreter</I>; however, given the various ways in which bytecodes can be executed, this term can be misleading. While &quot;Java interpreter&quot; is a reasonable name for a Java Virtual Machine that interprets bytecodes, virtual machines also use other techniques (such as just-in-time compiling) to execute bytecodes. Therefore, although all Java interpreters are Java Virtual Machines, not all Java Virtual Machines are Java interpreters.</P>
<P>When running on a Java Virtual Machine that is implemented in software on top of a host operating system, a Java program interacts with the host by invoking <I>native methods</I>. In Java, there are two kinds of methods: Java and native. A Java method is written in the Java language, compiled to bytecodes, and stored in class files. A native method is written in some other language, such as C, C++, or assembly, and compiled to the native machine code of a particular processor. Native methods are stored in a dynamically linked library whose exact form is platform specific. While Java methods are platform independent, native methods are not. When a running Java program calls a native method, the virtual machine loads the dynamic library that contains the native method and invokes it. As you can see in Figure 1-4, native methods are the connection between a Java program and an underlying host operating system.</P>
<P><IMG SRC="fig1-4.gif" tppabs="http://www.pbg.mcgraw-hill.com/betabooks/venners/images/fig1-4.gif" ALT="Figure 1-4"></P>

<P>You can use native methods to give your Java programs direct access to the resources of the underlying operating system. Their use, however, will render your program platform specific. This is because the dynamic libraries containing the native methods are platform specific. In addition, the use of native methods may render your program specific to a particular implementation of the Java Platform. One native method interface--the <I>Java Native Interface</I>, or <I>JNI</I>--enables native methods to work with any Java Platform implementation on a particular host computer. Vendors of the Java Platform, however, are not required to support JNI. They may provide their own proprietary native method interfaces in addition to (or in place of) JNI.</P>
<P>Java gives you a choice. If you want to access resources of a particular host that are unavailable through the Java API, you can write a platform-specific Java program that calls native methods. If you want to keep your program platform independent, however, you must call only Java methods and access the system resources of the underlying operating system through the Java API. </P>
<H3><P>The Class Loader Architecture</P>
</H3><P>One aspect of the Java Virtual Machine that plays an important role in both security and network-mobility is the class loader architecture. In the block diagrams of Figures 1-3 and 1-4, a single mysterious cube identifies itself as &quot;the class loader,&quot; but in reality there may be more than one class loader inside a Java Virtual Machine. Thus the class loader cube of the block diagram actually represents a subsystem that may involve many class loaders. The Java Virtual Machine has a flexible class loader architecture that allows a Java application to load classes in custom ways.</P>
<P>A Java application can use two types of class loaders: a &quot;primordial&quot; class loader and class loader objects. The primordial class loader (there is only one of them) is a part of the Java Virtual Machine implementation. For example, if a Java Virtual Machine is implemented as a C program on top of an existing operating system, then the primordial class loader will be part of that C program. The primordial class loader loads trusted classes, including the classes of the Java API, usually from the local disk.</P>
<P>At run-time, a Java application can install class loader objects that load classes in custom ways, such as by downloading class files across a network. The Java Virtual Machine considers any class it loads through the primordial class loader to be trusted, regardless of whether or not the class is part of the Java API. Classes it loads through class loader objects, however, it views with suspicion--by default, it considers them to be untrusted. While the primordial class loader is an intrinsic part of the virtual machine implementation, class loader objects are not. Instead, class loader objects are written in Java, compiled to class files, loaded into the virtual machine, and instantiated just like any other object. They are really just another part of the executable code of a running Java application. You can see a graphical depiction of this architecture in Figure 1-5.</P>
<P><IMG SRC="fig1-5.gif" tppabs="http://www.pbg.mcgraw-hill.com/betabooks/venners/images/fig1-5.gif" ALT="Figure 1-5"></P>

<P>Because of class loader objects, you don韙 have to know at compile-time all the classes that may ultimately take part in a running Java application. They enable you to dynamically extend a Java application at run-time. As it runs, your application can determine what extra classes it needs and load them through one or more class loader objects. Because you write the class loader in Java, you can load classes in any manner. You can download them across a network, get them out of some kind of database, or even calculate them on the fly.</P>
<P>For each class it loads, the Java Virtual Machine keeps track of which class loader--whether primordial or object--loaded the class. When a loaded class first refers to another class, the virtual machine requests the referenc<I>ed</I> class from the same class loader that originally loaded the referenc<I>ing</I> class. For example, if the virtual machine loads class <FONT FACE="Courier New">Volcano</FONT> through a particular class loader, it will attempt to load any classes <FONT FACE="Courier New">Volcano</FONT> refers to through the same class loader. If <FONT FACE="Courier New">Volcano</FONT> refers to a class named <FONT FACE="Courier New">Lava</FONT>, perhaps by invoking a method in class <FONT FACE="Courier New">Lava</FONT>, the virtual machine will request <FONT FACE="Courier New">Lava</FONT> from the class loader object that loaded <FONT FACE="Courier New">Volcano</FONT>. The <FONT FACE="Courier New">Lava</FONT> class returned by the class loader is dynamically linked with class <FONT FACE="Courier New">Volcano</FONT>.</P>
<P>Because the Java Virtual Machine takes this approach to loading classes, classes can by default only see other classes that were loaded by the same class loader. This is how Java韘 architecture enables you to create multiple <I>name-spaces</I> inside a single Java application. Each class loader in your running Java program maintains its own name-space, which is populated by the names of all the classes it has loaded.</P>
<P>A Java application can instantiate multiple class loader objects either from the same class or from multiple classes. It can, therefore, create as many (and as many different kinds of) class loader objects as it needs. Classes loaded by different class loaders are in different name-spaces and cannot gain access to each other unless the application explicitly allows it. When you write a Java application, you can segregate classes loaded from different sources into different name-spaces. In this way, you can use Java韘 class loader architecture to control any interaction between code loaded from different sources. You can prevent hostile code from gaining access to and subverting friendly code. </P>