Java Virtual Machine1

Published on May 2016 | Categories: Documents | Downloads: 31 | Comments: 0 | Views: 438
of 7
Download PDF   Embed   Report

Some information which i searched on Java Virtual Machine

Comments

Content

JAVA VIRTUAL MACHINE

Java Virtual Machine from Sun
Java Virtual Machine
Java Virtual Machine (JVM) - A program that runs under an operating system and interprets Java programs. The Java Virtual Machine ideally will not allow any harm to come to the computer because it has no control of the operating system and acts as if it is a separate computer. Thus, if a malicious Java program were to crash the Java Virtual Machine the operating system would remain stable. Another advantage of this mechanism is that different OSes can have their own Java Virtual Machines that should act identically. Thus Java should be able to be run across different platforms easily with no code changes. In the real world, however, this is not always the case.

The Java virtual machine (JVM) is the cornerstone of the Java and Java 2 platforms. It is the component of the technology responsible for its hardware- and operating systemindependence, the small size of its compiled code, and its ability to protect users from malicious programs. The Java virtual machine is an abstract computing machine. Like a real computing machine, it has an instruction set and manipulates various memory areas at run time. It is reasonably common to implement a programming language using a virtual machine; the best-known virtual machine may be the P-Code machine of UCSD Pascal. The first prototype implementation of the Java virtual machine, done at Sun Microsystems, Inc., emulated the Java virtual machine instruction set in software hosted by a handhold device that resembled a contemporary Personal Digital Assistant (PDA). Sun's current Java virtual machine implementations, components of its Java TM 2 SDK and Java TM 2 Runtime Environment products, emulate the Java virtual machine on Win32 and Solaris hosts in much more sophisticated ways. However, the Java virtual machine does not assume any particular implementation technology, host hardware, or host operating system. It is not inherently interpreted, but can just as well be implemented by compiling its instruction set to that of a silicon CPU. It may also be implemented in microcode or directly in silicon. The Java virtual machine knows nothing of the Java programming language, only of a particular binary format, the class file format. A class file contains Java virtual machine instructions (or bytecodes) and a symbol table, as well as other ancillary information. For the sake of security, the Java virtual machine imposes strong format and structural constraints on the code in a class file. However, any language with functionality that can be expressed in terms of a valid class file can be hosted by the Java virtual machine. Attracted by a generally available, machine-independent platform, implementors of other languages are turning to the Java virtual machine as a delivery vehicle for their languages.

JAVA VIRTUAL MACHINE

A Bit of History
The Java programming language is a general-purpose object-oriented concurrent language. Its syntax is similar to C and C++, but it omits many of the features that make C and C++ complex, confusing, and unsafe. The Java platform was initially developed to address the problems of building software for networked consumer devices. It was designed to support multiple host architectures and to allow secure delivery of software components. To meet these requirements, compiled code had to survive transport across networks, operate on any client, and assure the client that it was safe to run. The popularization of the World Wide Web made these attributes much more interesting. The Internet demonstrated how media-rich content could be made accessible in simple ways. Web browsers such as Mosaic enabled millions of people to roam the Net and made Web surfing part of popular culture. At last there was a medium where what you saw and heard was essentially the same whether you were using a Mac, PC, or UNIX machine, and whether you were connected to a high-speed network or a slow modem. A Web browser incorporating the Java platform is no longer limited to a predetermined set of capabilities. Visitors to Web pages incorporating dynamic content can be assured that their machines cannot be damaged by that content. Programmers can write a program once, and it will run on any machine supplying a Java runtime environment. Web enthusiasts soon discovered that the content supported by the Web's HTML document format was too limited. HTML extensions, such as forms, only highlighted those limitations, while making it clear that no browser could include all the features users wanted. Extensibility was the answer.

An introduction to the Java Virtual Machine
This chapter provides an introduction to the Java Virtual Machine (JVM). While it is important for you to be familiar with basic information concerning the JVM, unless you get into very advanced Java programming, the JVM is typically something you don't need to worry about. This chapter is for your information only. Before exploring the Java Virtual Machine, we will explain some of the terminology used in this chapter. First, the Java Virtual Machine (JVM) is the environment in which Java programs execute. The Java Virtual Machine specification essentially defines an abstract computer, and specifies the instructions that this computer can execute. These instructions are called bytecodes. Generally speaking, Java bytecodes are to the JVM what an instruction set is to a CPU. A bytecode is a byte-long instruction that the Java compiler generates, and the Java interpreter executes. When the compiler compiles a .java file, it produces a series of bytecodes and stores them in a .class file. The Java interpreter can then execute the bytecodes stored in the .class file. Other terminology used in this chapter involves Java applications and applets. It is sometimes appropriate to distinguish between a Java application and a Java applet. In some sections of this chapter, however, that distinction is inappropriate. In such cases, we will use the word app to refer to both Java applications and Java applets.

JAVA VIRTUAL MACHINE

It is important here to clarify what Java really is. Java is more than just a computer language; it is a computer environment. This is because Java is composed of two separate main elements, each of which is an essential part of Java: the design-time Java (the Java language itself) and the runtime Java (the JVM). This interpretation of the word Java is a more technical one. Interestingly enough, the practical interpretation of the word Java is that it stands for the runtime environment--not the language. When you say something like "this machine can run Java," what you really mean is that the machine supports the Java Runtime Environment (JRE); more precisely, it implements a Java Virtual Machine. A distinction should be made between the Java Virtual Machine Specification and an implementation of the Java Virtual Machine. The JVM specification is a document (available from Sun's web site) which defines how to implement a JVM. When an implementation of the JVM correctly follows this specification, it essentially ensures that Java apps can run on this implementation of the JVM with the same results those same Java apps produce when running on any other implementation of the JVM. The JVM specification ensures that Java programs will be able to run on any platform. The JVM specification is platform independent, because it can be implemented on any platform. Note that a specific implementation of the JVM is platform dependent. This is because the JVM implementation is the only portion of Java that directly interacts with the operating system (OS) of your computer. Because each OS is different, any specific JVM implementation must know how to interact with the specific OS for which it is intended. Having Java programs run under an implementation of the JVM guarantees a predictable runtime environment, because all implementations of the JVM conform to the JVM specification. Even though there are different implementations of the JVM, they all must meet certain requirements to guarantee portability. In other words, whatever differs among the various implementations does not affect portability. The JVM is responsible for performing the following functions:
• • • • •

Allocating memory for created objects Performing garbage collection Handling register and stack operations Calling on the host system for certain functions, such as device access Monitoring the security of Java apps

Throughout the remaining chapter, we will focus on the last function: security.

Java VM security
One of the JVM's most important roles is monitoring the security of Java apps. The JVM uses a specific mechanism to force certain security restrictions on Java apps. This mechanism (or security model) has the following roles:


Determines to what extent the code being run is "trusted" and assigns it the

JAVA VIRTUAL MACHINE

• •

appropriate level of access Assures that bytecodes do not perform illegal operations Verifies that every bytecode is generated correctly In the following sections, we will see how these security roles are taken care of in Java.

The security model
In this section, we will look at some of the different elements in Java's security model. In particular, we will examine the roles of the Java Verifier, the Security Manager and java.security package, and the Class Loader. These are some of the components that make Java apps secure.

The Java verifier
Every time a class is loaded, it must first go through a verification process. The main role of this verification process is to ensure that each bytecode in the class does not violate the specifications of the Java VM. Examples of bytecode violations are type errors and overflowed or underflowed arithmetic operations. The verification process is handled by the Java verifier, and it consists of the following four stages: 1. 2. 3. 4. Verifying the structure of class files. Performing system-level verifications. Validating bytecodes. Performing runtime type and access checks.

The first stage of the verifier is concerned with verifying the structure of the class file. All class files share a common structure; for example, they must always begin with what is called the magic number, whose value is 0xCAFEBABE. At this stage, the verifier also checks that the constant pool is not corrupted (the constant pool is where the class file's strings and numbers are stored). In addition, the verifier makes sure that there are no added bytes at the end of the class file. The second stage performs system-level verifications. This involves verifying the validity of all references to the constant pool, and ensuring that classes are subclassed properly. The third stage involves validating the bytecodes. This is the most significant and complex stage in the entire verification process. Validating a bytecode means checking that its type is valid and that its arguments have the appropriate number and type. The verifier also checks that method calls are passed the correct type and number of arguments, and that each external function returns the proper type. The final stage is where runtime checks take place. At this stage, externally referenced classes are loaded, and their methods are checked. The method check involves checking that the method calls match the signature of the methods in the external classes. The verifier also

JAVA VIRTUAL MACHINE

monitors access attempts by the currently loaded class to make sure that the class does not violate access restrictions. Another access check is done on variables to ensure that private and protected variables are not accessed illegally. From this exhaustive verification process, we can see how important the Java verifier is to the security model. It is also important to note that the verification process must be done at the verifier level, and not at the compiler's, since any compiler can be programmed to generate Java bytecodes. Clearly then, relying on the compiler to perform the verification process is dangerous, since the compiler can be programmed to bypass it. This point illustrates why the JVM is necessary. If you need more information on the Java verifier, please see the

Java Virtual

Machine Specification. The Security Manager and the java.security Package
One of the classes defined in the java.lang package is the SecurityManager class. This class checks the security policy on Java apps to determine if the running app has permission to perform certain dangerous operations. The security policy's main role is to determine access rights. In Java 1.1, the SecurityManager class was solely responsible for setting the security policy, but in Java 2 and above, a much more detailed and robust security model is achieved using the new java.security package. The SecurityManager class has several methods that begin with "check". In Java 1.1, the default implementation of those "check" methods was to throw a SecurityException. Since Java 2, the default implementation of most of the "check" methods calls SecurityManager.checkPermission(), and that method's default implementation in turn calls java.security.AccessController.checkPermission(). It is AccessController which is responsible for the actual algorithm for checking permissions. The SecurityManager class contains many methods used to check whether a particular operation is permitted. The checkRead() and checkWrite() methods, for example, check whether the method caller has the right to perform a read or write operation, respectively, to a specified file. They do this by calling checkPermission(), which in turn calls AccessController.checkPermission(). Many of the methods in the JDK use the SecurityManager before performing dangerous operations. The JDK does this for legacy reasons; SecurityManager existed in earlier versions of the JDK when there was a much more limited security model. In your apps, you may want to call AccessController.checkPermission() directly, instead of using the SecurityManager class (which calls the same method indirectly anyway). The static System.setSecurityManager() method can be used to load the default security manager into the environment. Now, whenever a Java app needs to perform a dangerous operation, it can consult with the SecurityManager object that is loaded into the environment. The way Java apps use the SecurityManager class is generally the same. An instance of SecurityManager is first created, either by using a special command line argument when the

JAVA VIRTUAL MACHINE

app is started ("-Djava.security.manager"), or in code similar to the following: SecurityManager security = System.getSecurityManager(); The System.getSecurityManager() method returns an instance of the currently loaded SecurityManager. If no SecurityManager has been set using the System.setSecurityManager() method, System.getSecurityManager() returns null; otherwise, it returns an instance of the SecurityManager that was loaded into the environment. Now, let's assume that the app wants to check whether it can read a file. It does so as follows: if (security != null) { security.checkRead (fileName); }

The if statement first checks whether a SecurityManager object exists, then it makes the call to the checkRead() method. If checkRead() does not permit the operation, a SecurityException is thrown and the operation never takes place; otherwise, all goes well. There is typically a security manager loaded when an applet is running, because most Java-enabled browsers automatically use one. An application, on the other hand, does not automatically use a security manager, unless one is loaded into the environment using the System.setSecurityManager() method, or from the command line when starting the application. To use the same security policy for an application as for an applet, you must make sure the security manager is loaded. In order to specify your own security policy, you will need to work with the classes in the java.security package. Important classes in this package include Policy, Permission, and AccessController. You should not subclass SecurityManager except as a last resort, and then with extreme caution. An in-depth discussion of the security package is outside the scope of this book. The default security policy should suffice for most beginning Java developers. When you do find you are concerned with more advanced security topics, or just for more information on the java.security package, please see the "Security Architecture" document in the JDK documentation.

The class loader
The class loader works alongside the security manager to monitor the security of Java apps. The main roles of the class loader are summarized below:
• • • •

Determines whether the class it is attempting to load has already been loaded Loads class files into the Virtual Machine Determines the permissions assigned to the loaded class in accordance with the security policy Provides certain information about loaded classes to the security manager

JAVA VIRTUAL MACHINE



Determines the path from which the class should be loaded (System classes are always loaded from the BOOTCLASSPATH)

Each instance of a class is associated with a class loader object, which is an instance of a subclass of the abstract class java.lang.ClassLoader. Class loading happens automatically when a class is instantiated. It is possible to create a custom class loader by subclassing ClassLoader or one of its existing subclasses, but in most cases this is not necessary. If you need more information about the class loader mechanism, see the documentation for java.lang.ClassLoader and the "Security Architecture" document in the JDK documentation. So far, we've seen how the Java verifier, the SecurityManager, and the class loader work to ensure the security of Java apps. In addition to these, there are other mechanisms not described in this chapter, such as those in the java.security package, which add to the security of Java apps. There is also a measure of security built into the Java language itself, but that is outside the scope of this chapter.

What about Just­In­Time compilers?
It is appropriate to include a brief discussion of Just-In-Time (JIT) compilers in this chapter. JIT compilers translate Java bytecodes into native machine instructions to be directly executed by the CPU. This obviously boosts the performance of Java apps. But if native instructions are executed instead of bytecodes, what happens to the verification process mentioned earlier? Actually, the verification process does not change because the Java verifier still verifies the bytecodes before they are translated.

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close