Docjar: A Java Source and Docuemnt Enginecom.*    java.*    javax.*    org.*    all    new    plug-in

Quick Search    Search Deep

org.apache.bcel.classfile.* (48)org.apache.bcel.generic.* (216)
org.apache.bcel.util.* (20)org.apache.bcel.verifier.* (48)
org.apache.bcel.verifier.exc.* (14)org.apache.bcel.verifier.statics.* (9)
org.apache.bcel.verifier.structurals.* (14)

org.apache.bcel: Javadoc index of package org.apache.bcel.


Package Samples:

org.apache.bcel.verifier: This package contains basic classes for the Byte Code Engineering Library and constants defined by the JVM specification .  
org.apache.bcel.verifier.structurals: BCEL's verifier JustIce is there to help you dump correct Java class files created or modified with BCEL.  
org.apache.bcel.classfile
org.apache.bcel.generic
org.apache.bcel.util
org.apache.bcel.verifier.exc
org.apache.bcel.verifier.statics

Classes:

ExecutionVisitor: This Visitor class may be used for a type-based Java Virtual Machine simulation. It does not check for correct types on the OperandStack or in the LocalVariables; nor does it check their sizes are sufficiently big. Thus, to use this Visitor for bytecode verifying, you have to make sure externally that the type constraints of the Java Virtual Machine instructions are satisfied. An InstConstraintVisitor may be used for this. Anyway, this Visitor does not mandate it. For example, when you visitIADD(IADD o), then there are two stack slots popped and one stack slot containing a Type.INT is pushed (where ...
PassVerifier: A PassVerifier actually verifies a class file; it is instantiated by a Verifier. The verification should conform with a certain pass as described in The Java Virtual Machine Specification, 2nd edition. This book describes four passes. Pass one means loading the class and verifying a few static constraints. Pass two actually verifies some other constraints that could enforce loading in referenced class files. Pass three is the first pass that actually checks constraints in the code array of a method in the class file; it has two parts with the first verifying static constraints and the second part ...
Subroutines: Instances of this class contain information about the subroutines found in a code array of a method. This implementation considers the top-level (the instructions reachable without a JSR or JSR_W starting off from the first instruction in a code array of a method) being a special subroutine; see getTopLevel() for that. Please note that the definition of subroutines in the Java Virtual Machine Specification, Second Edition is somewhat incomplete. Therefore, JustIce uses an own, more rigid notion. Basically, a subroutine is a piece of code that starts at the target of a JSR of JSR_W instruction and ...
LinkingConstraintException: Instances of this class are thrown by BCEL's class file verifier "JustIce" when a class file to verify does not pass the verification pass 3 because of a violation of a constraint that is usually only verified at run-time (pass 4). The Java Virtual Machine Specification, 2nd edition, states that certain constraints are usually verified at run-time for performance reasons (the verification of those constraints requires loading in and recursively verifying referenced classes) that conceptually belong to pass 3; to be precise, that conceptually belong to the data flow analysis of pass 3 (called pass ...
ClassLoader: Drop in replacement for the standard class loader of the JVM. You can use it in conjunction with the JavaWrapper to dynamically modify/create classes as they're requested. This class loader recognizes special requests in a distinct format, i.e., when the name of the requested class contains with "$$BCEL$$" it calls the createClass() method with that name (everything bevor the $$BCEL$$ is considered to be the package name. You can subclass the class loader and override that method. "Normal" classes class can be modified by overriding the modifyClass() method which is called just before defineClass(). ...
TargetLostException: Thrown by InstructionList.remove() when one or multiple disposed instruction are still being referenced by a InstructionTargeter object. I.e. the InstructionTargeter has to be notified that (one of) the InstructionHandle it is referencing is being removed from the InstructionList and thus not valid anymore. Making this an exception instead of a return value forces the user to handle these case explicitely in a try { ... } catch. The following code illustrates how this may be done: ... try { il.delete(start_ih, end_ih); } catch(TargetLostException e) { InstructionHandle[] targets = e.getTargets(); ...
InstructionFinder: InstructionFinder is a tool to search for given instructions patterns, i.e., match sequences of instructions in an instruction list via regular expressions. This can be used, e.g., in order to implement a peep hole optimizer that looks for code patterns and replaces them with faster equivalents. This class internally uses the Regexp package to search for regular expressions. A typical application would look like this: InstructionFinder f = new InstructionFinder(il); String pat = "IfInstruction ICONST_0 GOTO ICONST_1 NOP (IFEQ|IFNE)"; for(Iterator i = f.search(pat, constraint); i.hasNext(); ...
Class2HTML: Read class file(s) and convert them into HTML files. Given a JavaClass object "class" that is in package "package" five files will be created in the specified directory. "package"."class".html as the main file which defines the frames for the following subfiles. "package"."class"_attributes.html contains all (known) attributes found in the file "package"."class"_cp.html contains the constant pool "package"."class"_code.html contains the byte code "package"."class"_methods.html contains references to all methods and fields of the class All subfiles reference each other appropiately, e.g. clicking ...
ExceptionThrower: Denote an instruction that may throw a run-time or a linking exception (or both) during execution. This is not quite the truth as such; because all instructions may throw an java.lang.VirtualMachineError. These exceptions are omitted. The Lava Language Specification specifies exactly which RUN-TIME and which LINKING exceptions each instruction may throw which is reflected by the implementers. Due to the structure of the JVM specification, it may be possible that an Instruction implementing this interface returns a Class[] of size 0. Please note that we speak of an "exception" here when we mean ...
StringRepresentation: BCEL's Node classes (those from the classfile API that accept() Visitor instances) have toString() methods that were not designed to be robust, this gap is closed by this class. When performing class file verification, it may be useful to output which entity (e.g. a Code instance) is not satisfying the verifier's constraints, but in this case it could be possible for the toString() method to throw a RuntimeException. A (new StringRepresentation(Node n)).toString() never throws any exception. Note that this class also serves as a placeholder for more sophisticated message handling in future versions ...
StructuralCodeConstraintException: Instances of this class are thrown by BCEL's class file verifier "JustIce" when a class file to verify does not pass the verification pass 3 because of a violation of a structural constraint as described in the Java Virtual Machine Specification, 2nd edition, 4.8.2, pages 137-139. Note that the notion of a "structural" constraint is somewhat misleading. Structural constraints are constraints on relationships between Java virtual machine instructions. These are the constraints where data-flow analysis is needed to verify if they hold. The data flow analysis of pass 3 is called pass 3b in JustIce ...
InstructionConstants: This interface contains shareable instruction objects. In order to save memory you can use some instructions multiply, since they have an immutable state and are directly derived from Instruction. I.e. they have no instance fields that could be changed. Since some of these instructions like ICONST_0 occur very frequently this can save a lot of time and space. This feature is an adaptation of the FlyWeight design pattern, we just use an array instead of a factory. The Instructions can also accessed directly under their names, so it's possible to write il.append(Instruction.ICONST_0);
JavaWrapper: Java interpreter replacement, i.e., wrapper that uses its own ClassLoader to modify/generate classes as they're requested. You can take this as a template for your own applications. Call this wrapper with java org.apache.bcel.util.JavaWrapper <real.class.name> [arguments] To use your own class loader you can set the "bcel.classloader" system property which defaults to "org.apache.bcel.util.ClassLoader", e.g., with java org.apache.bcel.util.JavaWrapper -Dbcel.classloader=foo.MyLoader <real.class.name> [arguments]
StaticCodeInstructionOperandConstraintException: Instances of this class are thrown by BCEL's class file verifier "JustIce" when a class file to verify does not pass the verification pass 3 because of a violation of a static constraint as described in the Java Virtual Machine Specification, Second edition, 4.8.1, pages 133-137. The static constraints checking part of pass 3 is called pass 3a in JustIce. Static constraints on the operands of instructions in the code array are checked late in pass 3a and are described on page 134-137 in the Java Virtual Machine Specification, Second Edition.
InstructionHandle: Instances of this class give users a handle to the instructions contained in an InstructionList. Instruction objects may be used more than once within a list, this is useful because it saves memory and may be much faster. Within an InstructionList an InstructionHandle object is wrapped around all instructions, i.e., it implements a cell in a doubly-linked list. From the outside only the next and the previous instruction (handle) are accessible. One can traverse the list via an Enumeration returned by InstructionList.elements().
StaticCodeInstructionConstraintException: Instances of this class are thrown by BCEL's class file verifier "JustIce" when a class file to verify does not pass the verification pass 3 because of a violation of a static constraint as described in the Java Virtual Machine Specification, Second edition, 4.8.1, pages 133-137. The static constraints checking part of pass 3 is called pass 3a in JustIce. Static constraints on the instructions in the code array are checked early in pass 3a and are described on page 134 in the Java Virtual Machine Specification, Second Edition.
InstructionList: This class is a container for a list of Instruction objects. Instructions can be appended, inserted, moved, deleted, etc.. Instructions are being wrapped into InstructionHandles objects that are returned upon append/insert operations. They give the user (read only) access to the list structure, such that it can be traversed and manipulated in a controlled way. A list is finally dumped to a byte code array with getByteCode .
SyntheticRepository: This repository is used in situations where a Class is created outside the realm of a ClassLoader. Classes are loaded from the file systems using the paths specified in the given class path. By default, this is the value returned by ClassPath.getClassPath(). It is designed to be used as a singleton, however it can also be used with custom classpaths. /** Abstract definition of a class repository. Instances may be used to load classes from different sources and may be used in the Repository.setRepository method.
CodeExceptionGen: This class represents an exception handler, i.e., specifies the region where a handler is active and an instruction where the actual handling is done. pool as parameters. Opposed to the JVM specification the end of the handled region is set to be inclusive, i.e. all instructions between start and end are protected including the start and end instructions (handles) themselves. The end of the region is automatically mapped to be exclusive when calling getCodeException(), i.e., there is no difference semantically.
ClassParser: Wrapper class that parses a given Java .class file. The method parse returns a JavaClass object on success. When an I/O error or an inconsistency occurs an appropiate exception is propagated back to the caller. The structure and the names comply, except for a few conveniences, exactly with the JVM specification 1.0 . See this paper for further details about the structure of a bytecode file.
MethodGen: Template class for building up a method. This is done by defining exception handlers, adding thrown exceptions, local variables and attributes, whereas the `LocalVariableTable' and `LineNumberTable' attributes will be set automatically for the code. Use stripAttributes() if you don't like this. While generating code it may be necessary to insert NOP operations. You can use the `removeNOPs' method to get rid off them. The resulting method object can be obtained via the `getMethod()' method.
ConstantPoolGen: This class is used to build up a constant pool. The user adds constants via `addXXX' methods, `addString', `addClass', etc.. These methods return an index into the constant pool. Finally, `getFinalConstantPool()' returns the constant pool built up. Intermediate versions of the constant pool can be obtained with `getConstantPool()'. A constant pool has capacity for Constants.MAX_SHORT entries. Note that the first (0) is used by the JVM and that Double and Long constants need two slots.
CompoundInstruction: Wrapper class for `compound' operations, virtual instructions that don't exist as byte code, but give a useful meaning. For example, the (virtual) PUSH instruction takes an arbitray argument and produces the appropiate code at dump time (ICONST, LDC, BIPUSH, ...). Also you can use the SWITCH instruction as a useful template for either LOOKUPSWITCH or TABLESWITCH. The interface provides the possibilty for the user to write `templates' or `macros' for such reuseable code patterns.

Home | Contact Us | Privacy Policy | Terms of Service