| Home >> All >> org >> [ jxcl Javadoc ] |
| • | org.jxcl.cl.* (32) | • | org.jxcl.exception.* (1) | • | org.jxcl.graph.* (14) | • | org.jxcl.jxunit.* (33) |
| • | org.jxcl.reg.* (4) |
• org.jxcl: Javadoc index of package org.jxcl.
Package Samples:
• org.jxcl.cl
• org.jxcl.jxunit.textui
• org.jxcl.jxunit.reports
• org.jxcl.jxunit.cover.stmt
• org.jxcl.jxunit.frontend.ant
• org.jxcl.jxunit.runner
• org.jxcl.jxunit.framework
• org.jxcl.graph
• org.jxcl.exception
• org.jxcl.reg
Classes:
• JXunitTask: Ant task for running JXunit and JUnit. The JXunit Ant task is meant to be a plug-in replacement for the Ant JUnitTask. Whatever build.xml works with JUnitTask should behave identically with JXunitTask. The opposite is not true: using JXunitTask allows you to run coverage tests in addition to JUnit unit tests Parameter names / build file options are compatible with the build.xml options for JUnitTask as of Ant 1.5.3-1, so that if <junit> and </junit> are replaced with <jxunit> and </jxunit> respectively in the build.xml file, test behavior should be the same. Build file options ...
• StmtRegistry: Registry for statement coverage information. As JXunit-instrumented classes are loaded, they register their z$$z hit count arrays and are assigned an ID unique in the life of the registry. The registry maintains: hit counts , keyed on class name method end counter indexes , keyed on class and method name line number ranges , keyed on class and counter index This and other information in the registry allows it the generate a number of reports summarizing coverage at package level (soon) class level (now) method level (now) line level (soonish) The registry is associated with the JXunit class loader ...
• Directed: A graph consisting of vertices connected by directed, weighted edges. The graph is guaranteed to have at least an entry and an exit point and to always be well-formed, in the sense that there will be a path from the entry vertex to any other vertex in the graph, and there will be a path from any vertex in the graph to the exit vertex These graphs may be nested. In such a case both graphs will be well-formed the entry and exit points of the subgraph are in the graph all paths from the entry point of the parent to a point in the subgraph will pass through the entry point of the subgraph all paths ...
• JXClassLoader: Transforming class loader. Can be directed to instrument a set of classes, matching class names against a list of prefixes and another list excluding classes from instrumentation, the exclusion list taking priority. Will delegate loading to a parent class loader where explicitly directed to; otherwise will be the defining loader. By default the loading of classes whose names begin with java., javax., junit., org.apache.bcel., org.apache.tools.ant. and org.jxcl. is delegated. Classes whose names begin with a reserved prefix, currently test.data.Test , are synthesized instead of being loaded. This ...
• ClassAction: Add instrumentation at the class level, creating <clinit> if necessary. Three fields are added and initialized: z$$z , the int[] hit counts array z$$zID , a class identifier unique within this run z$$zStmtReg , reference to the StmtRegistry z$$zVer , a JXunit class file format version All of these fields are public final static . They are initialized by clinit when the class is loaded, running bytecode inserted by JXunit.
• CounterVertex: A CodeVertex which carries counter instrumentation and a label. The counter has an index. Whenever the flow of execution passes through this vertex, the counter code adds 1 to the hit count table, to z$$z[n] , where n is the counter index. Counter indexes are unique and assigned consecutively. They are not the same as vertex indexes. In the current revision of the software, counter vertices are also labeled with the counter index.
• MethodAction: Process a MethodGen method before and after graph creation and manipulation. A JXunitClassLoader can have any number of such pre/post-processors. The preprocessors will be applied in order before graph generation and then the postprocessors will be applied in reverse order after graph manipulation is complete. If any fatal errors occur, transformers must issue a warning message on System.err and either undo any changes or set method to null.
• MethodXformer: Process a MethodGen method before and after graph creation and manipulation. A JXClassLoader can have any number of such pre/post-processors. The preprocessors will be applied in order before graph generation and then the postprocessors will be applied in reverse order after graph manipulation is complete. If any fatal errors occur, transformers must issue a warning message on System.err and either undo any changes or set method to null.
• ClassFactory: Class synthesizer. Currently intended for debugging JXCL development and limited to instantiating classes with a no-argument constructor and a single method whose bytecode depends upon the base name of the class. By default classes whose name begins with test.data.Test will be synthesized. This can be set to a different string by a JXClassLoader method.
• GraphTransformer: Build the control flow graph for a method, apply an arbitrary number of GraphXformers to it, and then collapse the graph back to an instruction list. Exception handlers are collected from the control flow graph and made available to callers. XXX Debug statements should be removed when code is definitely stable. XXX
• Registry: A registry for storing JXCL run-time options. The registry stores key-value pairs, where the key takes the form of an array of Strings. The registry is sorted, but XXX there is currently no support for sequential access or partial-key access. This class is not thread-safe.
• MethodTransformer: Optionally preprocesses a method, optionally transforms its control flow graph, optionally postprocesses it. The list of preprocessors is applied in forward order before graph transformation. The corresponding list of postprocessors is applied in reverse order after graph transformation.
• TryStacks: Manages try/catch blocks. Adds subgraphs to the method graph for each exception handler, building the graph that GraphTransformer hangs bytecode off. This module must cope with the fact that the compiler may allocate exception handlers in no particular order.
• JXunitTest: Parameters for controlling an individual task. These are and must be compatible with names used in Ant build.xml build control files. Most are set by methods whose name is derived from the variable name -- for example fork is set by setFork(b) .
• TestStmtCoverage: This is derived from org.jxcl.cl.TestTransformer; it instruments the test-data classes and the classes synthesized by ClassFactory. All of the instrumented classes are run and checked to see that they produce normal output, despite the instrumentation ;-)
• Visitor: Methods for visiting a JXCL directed graph. Implementations can assume that a walk across the graph using Walker will touch every vertex and edge in the target graph and in every subgraph once and only once. Entry and exit points are in their graphs.
• TestVertexData: Vertex data is the additional data differentiating a CodeVertex from a simple Vertex. It consists of a bytecode position, a label, and the InstructionList. XXX This code tested a now-obsolete data structure; it should be beefed up or dropped.
• ClassXformer: Application-specific pre- and post-processors for JXCL classes. There may be any number of these. If pre/post-processors encounter fatal errors, they must issue a warning message to System.err and either undo or set clazz to null.
• CatchData: Data structure describing an exception handler. XXX There have been problems associated with generation of exception handlers. tryEnd should be used to get a handle of the last instruction in the vertex.
• SortedBlocks: Manages an index into the bytecode vertices in a method's control flow graph. The vertices (blocks) are indexed by their position in the original code. The blocks may be from different graphs in a set of nested graphs.
• GraphAction: Walk the control flow graph, adding counter vertices on all edges inbound to code vertices. XXX Except those likely to cause problems; need to review this code later to make sure that all possibilities are covered.
• JXRegistry: A registry for use by JXCL class loaders. Adds transformers to the class loader prior to use. Stores information collected while loading classes under a String array key. Dumps that information on request.
• GraphXformer: Transform the graph, possibly using information from ClassGen and MethodGen. If fatal errors occur, transformers must issue a warning message on System.err and either undo any changes or set cfg to null.
• Scheduler: Collects individual and batch tests during initial processing of the Ant build.xml file, then schedules tests for running. Before running any tests, batch tests are unpacked and attributes assigned.
| Home | Contact Us | Privacy Policy | Terms of Service |