Let's understand the structure of the Class file. Definition of a single class, module or interface is contained by each class file. A stream of 8-bit bytes is contained in the class file. In big-endian order, multi-byte data items are stores. Big-endian order is an order in which high bytes come first. JavaTpoint offers too many high quality services. Mail us on [email protected] , to get more information about given services.
Please mail your requirement at [email protected] Duration: 1 week to 2 week. Java Training Java Tutorial. Abstract class Interface Abstract vs Interface. Package Access Modifiers Encapsulation. Reinforcement Learning.
R Programming. React Native. Python Design Patterns. Python Pillow. Python Turtle. Verbal Ability. The 0th entry in stack represents the type of the bottom of the stack, and subsequent entries represent types of stack elements closer to the top of the operand stack. We shall refer to the bottom element of the stack as stack element 0, and to subsequent elements as stack element 1, 2 etc. It is an error if, for any index i , stack[ i ] represents a stack entry whose index is greater than the maximum operand stack size for the method.
This structure gives the contents of two locations in the operand stack or in the local variable array. If the location is a local variable, then:. It must not be the local variable with the highest index. The next higher numbered local variable contains the verification type top. If the location is an operand stack entry, then:.
The current location must not be the topmost location of the operand stack. The next location closer to the top of the operand stack contains the verification type top. The Exceptions attribute indicates which checked exceptions a method may throw. The Exceptions attribute has the following format:. A method should throw an exception only if at least one of the following three criteria is met:. The exception is an instance of RuntimeException or one of its subclasses. The exception is an instance of Error or one of its subclasses.
These requirements are not enforced in the Java Virtual Machine; they are enforced only at compile-time. The InnerClasses attribute has the following format:.
These rules imply that a nested class or interface member will have InnerClasses information for each enclosing class and for each immediate member. Each classes array entry contains the following four items:.
The remaining items in the classes array entry give information about C. It is used by a compiler to recover the original information when source code is not available. The flags are shown in Table 4. If a class file has a version number that is greater than or equal to Oracle's Java Virtual Machine implementation does not check the consistency of an InnerClasses attribute against a class file representing a class or interface referenced by the attribute.
A class must have an EnclosingMethod attribute if and only if it is a local class or an anonymous class. A class may have no more than one EnclosingMethod attribute. The EnclosingMethod attribute has the following format:. The Synthetic attribute was introduced in JDK release 1. The Synthetic attribute has the following format:.
The Signature attribute records generic signature information for any class, interface, constructor or member whose generic signature in the Java programming language would include references to type variables or parameterized types. The Signature attribute has the following format:. There can be no more than one SourceFile attribute in the attributes table of a given ClassFile structure. The SourceFile attribute has the following format:. It will not be interpreted as indicating the name of a directory containing the file or an absolute path name for the file; such platform-specific additional information must be supplied by the run-time interpreter or development tool at the time the file name is actually used.
There can be no more than one SourceDebugExtension attribute in the attributes table of a given ClassFile structure. The SourceDebugExtension attribute has the following format:.
It may be used by debuggers to determine which part of the Java Virtual Machine code array corresponds to a given line number in the original source file.
If LineNumberTable attributes are present in the attributes table of a given Code attribute, then they may appear in any order. Furthermore, multiple LineNumberTable attributes may together represent a given line of a source file; that is, LineNumberTable attributes need not be one-to-one with source lines.
The LineNumberTable attribute has the following format:. It may be used by debuggers to determine the value of a given local variable during the execution of a method. If LocalVariableTable attributes are present in the attributes table of a given Code attribute, then they may appear in any order.
There may be no more than one LocalVariableTable attribute per local variable in the Code attribute. The LocalVariableTable attribute has the following format:. It also indicates the index into the local variable array of the current frame at which that local variable can be found.
Each entry must contain the following five items:. The given local variable must be at index in the local variable array of the current frame. If LocalVariableTypeTable attributes are present in the attributes table of a given Code attribute, then they may appear in any order. There may be no more than one LocalVariableTypeTable attribute per local variable in the Code attribute.
The LocalVariableTypeTable attribute differs from the LocalVariableTable attribute in that it provides signature information rather than descriptor information. This difference is only significant for variables whose type is a generic reference type.
Such variables will appear in both tables, while variables of other types will appear only in LocalVariableTable. The LocalVariableTypeTable attribute has the following format:.
A class, interface, method, or field may be marked using a Deprecated attribute to indicate that the class, interface, method, or field has been superseded. A run-time interpreter or tool that reads the class file format, such as a compiler, can use this marking to advise the user that a superceded class, interface, method, or field is being referred to. The presence of a Deprecated attribute does not alter the semantics of a class or interface. The Deprecated attribute has the following format:.
The RuntimeVisibleAnnotations attribute records run-time-visible Java programming language annotations on the corresponding class, field, or method. The Java Virtual Machine must make these annotations available so they can be returned by the appropriate reflective APIs. The RuntimeVisibleAnnotations attribute has the following format:. Note that a maximum of run-time-visible Java programming language annotations may be directly attached to a program element.
Each value of the annotations table represents a single run-time-visible annotation on a program element. The annotation structure has the following format:. The items of the annotation structure are as follows:. Note that a maximum of element-value pairs may be contained in a single annotation. The tag item indicates the type of this annotation element-value pair. The other legal values for tag are listed with their interpretations in Table 4.
The value item represents the value of this annotation element. This item is a union. The tag item, above, determines which item of the union is to be used:. For example, V for Void. Note that a maximum of elements are permitted in an array-typed element value. The RuntimeInvisibleAnnotations attribute is similar to the RuntimeVisibleAnnotations attribute, except that the annotations represented by a RuntimeInvisibleAnnotations attribute must not be made available for return by reflective APIs, unless the Java Virtual Machine has been instructed to retain these annotations via some implementation-specific mechanism such as a command line flag.
In the absence of such instructions, the Java Virtual Machine ignores this attribute. The RuntimeInvisibleAnnotations attribute records run-time-invisible Java programming language annotations on the corresponding class, method, or field.
The RuntimeInvisibleAnnotations attribute has the following format:. Note that a maximum of run-time-invisible Java programming language annotations may be directly attached to a program element. Each value of the annotations table represents a single run-time-invisible annotation on a program element.
The RuntimeVisibleParameterAnnotations attribute records run-time-visible Java programming language annotations on the parameters of the corresponding method.
The RuntimeVisibleParameterAnnotations attribute has the following format:. The sequence of values in the table corresponds to the sequence of parameters in the method descriptor. The RuntimeInvisibleParameterAnnotations attribute is similar to the RuntimeVisibleParameterAnnotations attribute, except that the annotations represented by a RuntimeInvisibleParameterAnnotations attribute must not be made available for return by reflective APIs, unless the Java Virtual Machine has specifically been instructed to retain these annotations via some implementation-specific mechanism such as a command line flag.
The RuntimeInvisibleParameterAnnotations attribute records run-time-invisible Java programming language annotations on the parameters of the corresponding method. The RuntimeInvisibleParameterAnnotations attribute has the following format:. The AnnotationDefault attribute has the following format:. There can be no more than one BootstrapMethods attribute in the attributes table of a given ClassFile structure. The BootstrapMethods attribute has the following format:.
This process is known as format checking. The first four bytes must contain the right magic number. All recognized attributes must be of the proper length. The class file must not be truncated or have extra bytes at the end. The constant pool must not contain any superficially unrecognizable information. This check for basic class file integrity is necessary for any interpretation of the class file contents. Format checking is distinct from bytecode verification.
Both are part of the verification process. Historically, format checking has been confused with bytecode verification, because both are a form of integrity check. The static constraints on a class file are those defining the well-formedness of the file. With the exception of the static constraints on the Java Virtual Machine code of the class file, these constraints have been given in the previous sections. The static constraints on the Java Virtual Machine code in a class file specify how Java Virtual Machine instructions must be laid out in the code array and what the operands of individual instructions must be.
The static constraints on the instructions in the code array are as follows:. The opcode of the first instruction in the code array begins at index 0. If the class file version number is For each instruction in the code array except the last, the index of the opcode of the next instruction equals the index of the opcode of the current instruction plus the length of that instruction, including all its operands. The wide instruction is treated like any other instruction for these purposes; the opcode specifying the operation that a wide instruction is to modify is treated as one of the operands of that wide instruction.
That opcode must never be directly reachable by the computation. The static constraints on the operands of instructions in the code array are as follows:. The target of a jump or branch instruction must never be the opcode used to specify the operation to be modified by a wide instruction; a jump or branch target may be the wide instruction itself.
Each target, including the default, of each tableswitch instruction must be the opcode of an instruction within this method. Each tableswitch instruction must have a number of entries in its jump table that is consistent with the value of its low and high jump table operands, and its low value must be less than or equal to its high value. No target of a tableswitch instruction may be the opcode used to specify the operation to be modified by a wide instruction; a tableswitch target may be a wide instruction itself.
Each target, including the default, of each lookupswitch instruction must be the opcode of an instruction within this method.
Each lookupswitch instruction must have a number of match-offset pairs that is consistent with the value of its npairs operand.
The match-offset pairs must be sorted in increasing numerical order by signed match value. No target of a lookupswitch instruction may be the opcode used to specify the operation to be modified by a wide instruction; a lookupswitch target may be a wide instruction itself. The constant pool entry referenced by that index must be of type:.
In addition, the subsequent constant pool index must also be a valid index into the constant pool, and the constant pool entry at that index must not be used.
The third and fourth operand bytes of each invokedynamic instruction must have the value zero. The fourth operand byte of each invokeinterface instruction must have the value zero. No anewarray instruction may be used to create an array of more than dimensions. The new instruction cannot be used to create an array. A multianewarray instruction must be used only to create an array of a type that has at least as many dimensions as the value of its dimensions operand.
That is, while a multianewarray instruction is not required to create all of the dimensions of the array type referenced by its indexbyte operands, it must not attempt to create more dimensions than are in the array type. The dimensions operand of each multianewarray instruction must not be zero. The structural constraints on the code array specify constraints on relationships between Java Virtual Machine instructions.
The structural constraints are as follows:. Each instruction must only be executed with the appropriate type and number of arguments in the operand stack and local variable array, regardless of the execution path that leads to its invocation. An instruction operating on values of type int is also permitted to operate on values of type boolean , byte , char , and short. At no point during execution can the order of the local variable pair holding a value of type long or double be reversed or the pair split up.
At no point can the local variables of such a pair be operated on individually. No local variable or local variable pair, in the case of a value of type long or double can be accessed before it is assigned a value. At no point during execution can more values be popped from the operand stack than it contains. If an invokespecial instruction names an instance initialization method from a class that is not the current class or a superclass, and the target reference on the operand stack is a class instance created by an earlier new instruction, then invokespecial must name an instance initialization method from the class of that class instance.
An instance initialization method must never be invoked on an initialized class instance. When any instance method is invoked or when any instance variable is accessed, the class instance that contains the instance method or instance variable must already be initialized. However, instance fields of this that are declared in the current class may be assigned before calling any instance initialization method.
In addition, the type of the target of an invokespecial instruction must be assignment compatible with the current class, unless an instance initialization method is being invoked. Each return instruction must match its method's return type:. If the method returns a boolean , byte , char , short , or int , only the ireturn instruction may be used. If the method returns a float , long , or double , only an freturn , lreturn , or dreturn instruction, respectively, may be used. All instance initialization methods, class or interface initialization methods, and methods declared to return void must use only the return instruction.
If getfield or putfield is used to access a protected field declared in a superclass that is a member of a different run-time package than the current class, then the type of the class instance being accessed must be the same as or a subclass of the current class. If invokevirtual or invokespecial is used to access a protected method declared in a superclass that is a member of a different run-time package than the current class, then the type of the class instance being accessed must be the same as or a subclass of the current class.
If the descriptor type is boolean , byte , char , short , or int , then the value must be an int. If the descriptor type is float , long , or double , then the value must be a float , long , or double , respectively.
The type of every value stored into an array by an aastore instruction must be a reference type. The component type of the array being stored into by the aastore instruction must also be a reference type. Each athrow instruction must throw only values that are instances of class Throwable or of subclasses of Throwable.
Execution never falls off the bottom of the code array. No return address a value of type returnAddress may be loaded from a local variable. Subroutines can be nested when using try - finally constructs from within a finally clause. Each instance of type returnAddress can be returned to at most once. If a ret instruction returns to a point in the subroutine call chain above the ret instruction corresponding to a given instance of type returnAddress , then that instance can never be used as a return address.
Even though a compiler for the Java programming language must only produce class files that satisfy all the static and structural constraints in the previous sections, the Java Virtual Machine has no guarantee that any file it is asked to load was generated by that compiler or is properly formed. Applications such as web browsers do not download source code, which they then compile; these applications download already-compiled class files. The browser needs to determine whether the class file was produced by a trustworthy compiler or by an adversary attempting to exploit the Java Virtual Machine.
An additional problem with compile-time checking is version skew. A user may have successfully compiled a class, say PurchaseStockOptions , to be a subclass of TradingClass. But the definition of TradingClass might have changed since the time the class was compiled in a way that is not compatible with pre-existing binaries. Methods might have been deleted or had their return types or modifiers changed.
Fields might have changed types or changed from instance variables to class variables. The access modifiers of a method or variable may have changed from public to private. Because of these potential problems, the Java Virtual Machine needs to verify for itself that the desired constraints are satisfied by the class files it attempts to incorporate. Linking-time verification enhances the performance of the interpreter.
Expensive checks that would otherwise have to be performed to verify constraints at run time for each interpreted instruction can be eliminated. The Java Virtual Machine can assume that these checks have already been performed. For example, the Java Virtual Machine will already know the following:. There are no operand stack overflows or underflows. All local variable uses and stores are valid. The arguments to all the Java Virtual Machine instructions are of valid types.
The checks performed include the following:. Checking that every class except Object has a direct superclass. Checking that all field references and method references in the constant pool have valid names, valid classes, and a valid type descriptor. Note that these checks do not ensure that the given field or method actually exists in the given class, nor do they check that the type descriptors given refer to real classes.
They ensure only that these items are well formed. More detailed checking is performed when the bytecodes themselves are verified, and during resolution. There are two strategies that Java Virtual Machine implementations may use for verification:.
Verification by type checking must be used to verify class files whose version number is greater than or equal to Verification by type inference must be supported by all Java Virtual Machine implementations, except those conforming to the Java ME CLDC and Java Card profiles, in order to verify class files whose version number is less than A class file whose version number is greater than or equal to If, and only if, a class file's version number equals This is a pragmatic adjustment, designed to ease the transition to the new verification discipline.
Many tools that manipulate class files may alter the bytecodes of a method in a manner that requires adjustment of the method's stack map frames. If a tool does not make the necessary adjustments to the stack map frames, type checking may fail even though the bytecode is in principle valid and would consequently verify under the old type inference scheme. To allow implementors time to adapt their tools, Java Virtual Machine implementations may fall back to the older verification discipline, but only for a limited time.
In cases where type checking fails but type inference is invoked and succeeds, a certain performance penalty is expected. Such a penalty is unavoidable. It also should serve as a signal to tool vendors that their output needs to be adjusted, and provides vendors with additional incentive to make these adjustments. In summary, failover to verification by type inference supports both the gradual addition of stack map frames to the Java SE platform if they are not present in a version If a Java Virtual Machine implementation ever attempts to perform verification by type inference on version This means that a Java Virtual Machine implementation cannot choose to resort to type inference in once case and not in another.
It must either reject class files that do not verify via type checking, or else consistently failover to the type inferencing verifier whenever type checking fails. The type checker enforces type rules that are specified by means of Prolog clauses. English language text is used to describe the type rules in an informal way, while the Prolog clauses provide a formal specification. The intent is that a stack map frame must appear at the beginning of each basic block in a method.
The stack map frame specifies the verification type of each operand stack entry and of each local variable at the start of each basic block. The type checker reads the stack map frames for each method with a Code attribute and uses these maps to generate a proof of the type safety of the instructions in the Code attribute.
A class is type safe if all its methods are type safe, and it does not subclass a final class. The Prolog predicate classIsTypeSafe assumes that Class is a Prolog term representing a binary class that has been successfully parsed and loaded.
This specification does not mandate the precise structure of this term, but does require that certain predicates be defined upon it. For example, we assume a predicate classMethods Class, Methods that, given a term representing a class as described above as its first argument, binds its second argument to a list comprising all the methods of the class, represented in a convenient form described later.
Iff the predicate classIsTypeSafe is not true, the type checker must throw the exception VerifyError to indicate that the class file is malformed.
Otherwise, the class file has type checked successfully and bytecode verification has completed successfully. The rest of this section explains the process of type checking in detail:.
We stipulate the existence of 22 Prolog predicates "accessors" that have certain expected behavior but whose formal definitions are not given in this specification. Extracts the name, ClassName , of the class Class. True iff the class, Class , is an interface.
True iff the class, Class , is not a final class. Extracts the name, SuperClassName , of the superclass of class Class. Extracts a list, Interfaces , of the direct superinterfaces of the class Class. Extracts a list, Methods , of the methods declared in the class Class. Extracts a list, Attributes , of the attributes of the class Class. Each attribute is represented as a functor application of the form attribute AttributeName, AttributeContents , where AttributeName is the name of the attribute.
The format of the attribute's contents is unspecified. Extracts the defining class loader, Loader , of the class Class. True iff the class loader Loader is the bootstrap class loader. True iff there exists a class named Name whose representation in accordance with this specification when loaded by the class loader InitiatingLoader is ClassDefinition. Extracts the name, Name , of the method Method.
Extracts the access flags, AccessFlags , of the method Method. Extracts the descriptor, Descriptor , of the method Method. Extracts a list, Attributes , of the attributes of the method Method. True iff Method in class Class is not final. True iff there is a member named MemberName with descriptor MemberDescriptor in the class MemberClass and it is protected.
True iff there is a member named MemberName with descriptor MemberDescriptor in the class MemberClass and it is not protected. Converts a method descriptor, Descriptor , into a list of verification types, ArgTypeList , corresponding to the method argument types, and a verification type, ReturnType , corresponding to the return type.
Extracts the instruction stream, ParsedCode , of the method Method in Class , as well as the maximum operand stack size, MaxStack , the maximal number of local variables, FrameSize , the exception handlers, Handlers , and the stack map StackMap.
True iff the package names of Class1 and Class2 are the same. True iff the package names of Class1 and Class2 are different. When type checking a method's body, it is convenient to access information about the method.
For this purpose, we define an environment , a six-tuple consisting of:. We specify accessors to extract information from the environment. We specify additional predicates to extract higher-level information from the environment. Finally, we specify a general predicate used throughout the type rules:. The principle guiding the determination as to which accessors are stipulated and which are fully specified is that we do not want to over-specify the representation of the class file.
Providing specific accessors to the Class or Method term would force us to completely specify the format for a Prolog term representing the class file. The type checker enforces a type system based upon a hierarchy of verification types , illustrated below. The only exceptions are the field descriptors B , C , S , and Z , all of which correspond to the verification type int.
The verification types which are not reference types in the Java programming language have subtype rules of the form:. That is, v is a subtype of X if the direct supertype of v is a subtype of X. The rules are:. These subtype rules are not necessarily the most obvious formulation of subtyping. There is a clear split between subtyping rules for reference types in the Java programming language, and rules for the remaining verification types. The split allows us to state general subtyping relations between Java programming language reference types and other verification types.
These relations hold independently of a Java reference type's position in the type hierarchy, and help to prevent excessive class loading by a Java Virtual Machine implementation. We also have a rule that says subtyping is reflexive, so together these rules cover most verification types that are not reference types in the Java programming language.
Subtype rules for the reference types in the Java programming language are specified recursively with isJavaAssignable. For assignments, interfaces are treated like Object.
Array types are subtypes of Object. The intent is also that array types are subtypes of Cloneable and java. Subtyping between arrays of primitive type is the identity relation. Individual bytecode instructions are represented in Prolog as terms whose functor is the name of the instruction and whose arguments are its parsed operands. For example, an aload instruction is represented as the term aload N , which includes the index N that is the operand of the instruction.
The instructions as a whole are represented as a list of terms of the form:. For example, instruction 21, aload 1. The order of instructions in this list must be the same as in the class file. A few instructions have operands that are constant pool entries representing fields, methods, and dynamic call sites.
Such structures are represented as functor applications of the form:. For example, a getfield instruction whose operand was an index into the constant pool that refers to a field foo of type F in class Bar would be represented as getfield field 'Bar', 'foo', 'F'. For example, an ldc instruction for loading the integer 91 would be encoded as ldc int Stack map frames are represented in Prolog as a list of terms of the form:. The order of stack map frames in this list must be the same as in the class file.
TypeState has the form:. Locals is a list of verification types, such that the Nth element of the list with 0-based indexing represents the type of local variable N. If any local variable in Locals has the type uninitializedThis , then Flags has the single element flagThisUninit , otherwise it is an empty list.
OperandStack is a list of types, such that the first element represents the type of the top of the operand stack, and the elements below the top follow in the appropriate order. Types of size 2 long and double are represented by two entries, with the first entry being top and the second one being the type itself. For example, a stack with a double , an int , and a long would be represented as [top, double, int, top, long].
Reference types other than array types are represented using the functor class. Array types are represented by applying the functor arrayOf to an argument denoting the component type of the array. The verification type uninitialized offset is represented by applying the functor uninitialized to an argument representing the numerical value of the offset. Other verification types are represented in prolog as atoms whose name denotes the verification type in question. Flags is a list which may either be empty or have the single element flagThisUninit.
This flag is used in constructors, to mark type states where initialization of this has not yet been completed. In such type states, it is illegal to return from the method. Therefore, we require an explicit check on the length of the operand stacks whose assignability is desired.
The length of the operand stack must not exceed the declared maximum stack length. The following clause accesses the I'th element of the operand stack from a type state. The predicates given below take this into account, allowing the rest of the specification to abstract from this issue. Pop an individual type off the stack. More precisely, if the logical top of the stack is some subtype of the specified type, Type , then pop it. If a type occupies two stack slots, the logical top of stack type is really the type just below the top, and the top of stack is the unusable type top.
Push a logical type onto the stack. The exact behavior varies with the size of the type. If the pushed type is of size 1, we just push it onto the stack. If the pushed type is of size 2, we push it, and then push top. Category 1 types occupy a single stack slot.
Popping a logical type of category 1, Type , off the stack is possible if the top of the stack is Type and Type is not top otherwise it could denote the upper half of a category 2 type.
The result is the incoming stack, with the top slot popped off. Friday, July 9, What is class file in Java?
What is the class file in Java? Class file i n Java is compiled from of Java source file. When we compile a Java program written in a Java source file ended with a.
One Java source file can only contain one public class, and its name must match with the name of the file like HelloWorld. In fact, this combination of a class file , bytecode, and JVM makes Java achieves platform independence.
If anyone asks what is byte code in Java, is it machine instruction? You can answer them that it's just meant for JVM and not for a machine.
When you run a Java program as described in this step-by-step tutorial for running a java program using the java command, we provide the name of the class file which contains the main method in Java.
JVM first loads that file and executes the main method, which is the entry point of the Java application.
0コメント