Sponsored Link •
A key component of Java is the Java class file -- a precisely defined file format to which Java programs are compiled. The class file can be loaded by any Java Virtual Machine implementation and is the vehicle for the transmission of compiled Java across networks. Here's a hands-on introduction to the Java class file.
Welcome to another installment of "Under the Hood." In last month's article I discussed the Java Virtual Machine, or JVM, the abstract computer for which all Java programs are compiled. If you are unfamiliar with the JVM, you may want to read last month's article before this one. In this article I provide a glimpse into the basic structure and lifestyle of the Java class file.
Born to travel
The Java class file is a precisely defined format for compiled Java. Java source code is compiled into class files that can be loaded and executed by any JVM. The class files may travel across a network before being loaded by the JVM.
In fact, if you are reading this article via a Java-capable browser, class files for the simulation applet at the end of the article are flying across the Internet to your computer right now. If you'd like to listen in on them (and your computer has audio capability), push the following button:
Sounds like they're having fun, huh? That's in their nature. Java class files were designed to travel well. They are platform-independent, so they will be welcome in more places. They contain bytecodes, the compact instruction set for the JVM, so they can travel light. Java class files are constantly zipping through networks at breakneck speed to arrive at JVMs all over the world.
What's in a class file?
The Java class file contains everything a JVM needs to know about one Java class or interface. In their order of appearance in the class file, the major components are: magic, version, constant pool, access flags, this class, super class, interfaces, fields, methods, and attributes.
Information stored in the class file often varies in length -- that is, the actual length of the information cannot be predicted before loading the class file. For instance, the number of methods listed in the methods component can differ among class files, because it depends on the number of methods defined in the source code. Such information is organized in the class file by prefacing the actual information by its size or length. This way, when the class is being loaded by the JVM, the size of variable-length information is read first. Once the JVM knows the size, it can correctly read in the actual information.
Information is generally written to the class file with no space or padding between consecutive pieces of information; everything is aligned on byte boundaries. This helps keeps class files petite so they will be aerodynamic as they fly across networks.
The order of class file components is strictly defined so JVMs can know what to expect, and where to expect it, when loading a class file. For example, every JVM knows that the first eight bytes of a class file contain the magic and version numbers, that the constant pool starts on the ninth byte, and that the access flags follow the constant pool. But because the constant pool is variable-length, it doesn't know the exact whereabouts of the access flags until it has finished reading in the constant pool. Once it has finished reading in the constant pool, it knows the next two bytes will be the access flags.