The Java programming language, developed at Sun Microsystems under the guidance of Net luminaries James Gosling and Bill Joy
Historically, interpreters have been considered slow, but Java is not a traditional interpreted language. In addition to compiling source code down to portable bytecode, Java has also been carefully designed so that software implementations of the runtime system can further optimize their performance by compiling bytecode to native machine code on the fly. This is called just-in-time (JIT) or dynamic compilation. With JIT compilation, Java code can execute as fast as native code and maintain its transportability and The problem with a traditional JIT compilation is that optimizing code takes time. So a JIT compiler can produce decent results but may suffer a significant latency when the application starts up. To address this, Sun's compiler technology, called HotSpot, uses a trick called adaptive compilation. HotSpot starts out as a normal Java bytecode interpreter, but with a difference: it measures (profiles) the code as it is executing to see what parts are being executed repeatedly. Once it knows which parts of the code are crucial to performance, HotSpot compiles those sections into optimal native machine code. Since it compiles only a small portion of the program into machine code, it can afford to take the time necessary to optimize those portions. The rest of the program may not need to be compiled at alljust
A natural question to ask at this point is, Why throw away all this good profiling information each time an application shuts down? Well, Sun has partially broached this topic with the release of Java 5.0 through the use of shared, read-only classes that are stored persistently in an optimized form.
To display the value of CLASSPATH under Windows, use this command: C:\> set classpath To clear any CLASSPATH value, use this command under Windows: C:\> set classpath=
To check the version of Java, use the -version switch with the java command. Type the following at the command prompt and press Enter: C:\> java -version the java command can be used to launch an "executable" Java archive (JAR) file: % java -jar spaceblaster.jar In this case, the JAR file is annotated with the name of the class containing the main( ) method and the classpath becomes the JAR file itself. Java allows any number of system property values to be passed to the application when the VM is started. System properties are simply name-value string pairs that are available to the application through the static System.getProperty( ) method. You can use these properties as a more structured and portable alternative to command-line arguments and environment variables for providing general configuration information to your application at startup. Each system property is passed to the interpreter on the command line using the -D option followed by name=value. For example: % java -Dstreet=sesame -Dscene=alley animals.birds.BigBird The value of the street property is then accessible this way:
A useful tool to know about is the javap command. With javap, you can print a description of a compiled class. You don't have to have the source code, and you don't even have to know exactly where it is, only that it is in your classpath. For example: % javap java.util.Stack This is very useful if you don't have other documentation handy and can also be helpful in debugging classpath problems. Using javap you can determine whether a class is in the classpath and possibly even which version you are looking at (many classpath issues involve duplicate classes in the classpath). If you are feeling really adventurous, you can try javap with the -c option, which causes it to also print the JVM instructions for each method in the
jar -cvf jarFile path [ path ] [ ... ] Create jarFile containing path(s). jar -tvf jarFile [ path ] [ ... ] List the contents of jarFile, optionally showing just path(s). jar -xvf jarFile [ path ] [ ... ] Extract the contents of jarFile, optionally extracting just path(s). In these commands, the letters c, t, and x tell jar whether it is creating an archive, listing an archive's contents, or extracting files from an archive. The f means that the next argument is the name of the JAR file on which to operate. The v tells jar to be verbose when displaying information about files. In verbose mode, you get information about file sizes, modification times, and compression ratios. If you're creating an archive, the files and directories you list are placed in it. If you're extracting, only the filenames you list are extracted from the archive. (If you don't list any files, jar extracts everything in the archive.) % jar -cvf spaceblaster.jar spaceblaster jar creates the file spaceblaster.jar and adds the directory spaceblaster, adding the directories and files within spaceblaster to the archive. In verbose mode, jar reports the savings gained by compressing the files in the archive. We can unpack the archive with this command: % jar xvf spaceblaster.jar Likewise, we can extract an individual file or directory with: % jar xvf spaceblaster.jar filename
Note that the jar command automatically adds a directory called META-INF to our archive. The META-INF directory holds files describing the contents of the JAR file. It always contains at least one file: MANIFEST.MF. The MANIFEST.MF file can contain a "packing list" naming the files in the archive along with a user-definable set of attributes for each entry. The manifest is a text file containing a set of lines in the form keyword: value. In Java 1.2 and later, the manifest is by default empty and contains only JAR file version information: Manifest-Version: 1.0
You can add your own information to the manifest descriptions by specifying your own supplemental, manifest file when you create the archive. This is one possible place to store other simple kinds of attribute information about the files in the archive, perhaps version or authorship information. For example, we can create a file with the following keyword: value lines: Name: spaceblaster/images/planetoid.gif RevisionNumber: 42.7 Artist-Temperament: moody To add this information to the manifest in our archive, place it in a file called myManifest.mf and give the following jar command: % jar -cvmf myManifest.mf spaceblaster.jar spaceblaster We included an additional option, m, which specifies that jar should read additional manifest information from the file given on the command line. How does jar know which file is which? Because m is before f, it expects to find the manifest information before the name of the JAR file it will create. If you think that's awkward, you're right; get the names in the wrong order, and jar does the wrong thing. Be careful.
Aside from attributes, you can put a few special values in the manifest file. One of these, Main-Class, allows you to specify the class containing the primary main( ) method for an application contained in the JAR: Main-Class: com.oreilly.Game If you add this to your JAR file manifest (using the m option described earlier), you can run the application directly from the JAR: % java -jar spaceblaster.jar More importantly, under Mac OS X, Windows, and other GUI environments, you can simply click on the JAR file to launch the application. The interpreter looks for the Main-Class value in the manifest, then loads the named class as the application's initial class.
Pack200 is a new archive format introduced with Java 5.0 that is optimized for storing compiled Java class files. Pack200 is not a new form of compression but rather a super-efficient layout for class information that eliminates many types of waste and redundancy across many classes. You can convert a JAR to and from Pack200 format with the pack200 and unpack200 commands supplied with the JDK. For example, to convert foo.jar to foo.pack.gz, use the pack200 command: % pack200 foo.pack.gz foo.jar To convert foo.pack.gz to foo.jar: % unpack200 foo.pack.gz foo.jar