public class ClassDep extends Object
jartool, to create a JAR file containing precisely those classes.
The following items are discussed below:
java -jar install_dir/lib/classdep.jar \ -cp input_classpath processing_options output_options
where install_dir is the directory where the Apache River release is installed. Note that the options for this tool can be specified in any order, and can be intermixed.
-cp class path value,
is an argument to the
ClassDep tool itself and should
include all of the classes that might need to be included in the
dependency analysis. Typically this will include all of your application
classes, classes from the Apache River release, and any other classes on which
your classes might depend. It is safe to include more classes than are
actually necessary (since the purpose of this tool is, after all, to
determine which subset of these classes is actually necessary), but it is
not necessary to include any classes that are part of the Java 2 SDK.
The class path should be in the form of a list of directories or JAR
files, delimited by a colon (":") on UNIX platforms and a semi-colon
(";") on Microsoft Windows platforms. The order of locations in the path
does not matter. If you use JAR files, any
manifest entries in those JAR files are ignored, so you must include the
values of those manifest entries explicitly in the path, or errors may
result. For example, if you include
jini-ext.jar then you
should explicitly include
jini-core.jar as well, because
jini-core.jar is in the
In general, you only need to specify concrete classes as roots, not
interface types. When analyzing classes for the class path of an
application, you typically need to include the top-level class (the one
main method). When analyzing classes for the
codebase of a service, you typically need to include the top-level proxy
classes used by the service, any trust verifier classes for those
proxies, and any custom entry classes used by the service for lookup
service attributes. Also when analyzing classes for the codebase of a
service, if the service's proxy can return leases, registration objects,
or other proxies, or if your service generates events, and if those
objects are only referenced by interface type in the top-level proxy, not
by concrete class, then you also need to include the concrete classes of
those other objects. In all cases, you typically need to include any stub
classes that you generated with the
-newdirbehavioroptions is specified. The directory must contain at least one filename separator character and be one of the directories specified in input_classpath, or when the old behavior is effective it can be a subdirectory of one of the directories on the input_classpath. Each class in the tree needs to be in a package that is defined to be "inside" the graph (as described further below).
-newdirbehavior options is set the
-outroot options can be used to include/exclude particular
subtrees from the potential set of roots. When the old behavior is effective
all classes are considered as root, but can be excluded through the
-inrootpackage-prefix (only valid with
-outrootoptions. If not specified all found classes are considered roots. This option can be specified zero or more times. Note that the argument to
-inrootis a package namespace (delimited by "."), not a directory.
-outrootpackage-prefix (only valid with
rootdirelement, any classes that are in the given package or a subpackage of it are not treated as roots. This option can be specified zero or more times. Note that the argument to
-outrootis a package namespace (delimited by "."), not a directory.
-prunepackage-prefix (old behavior only)
-pruneis a package namespace (delimited by "."), not a directory.
-skip option (described further below) can be used to
exclude specific classes from the set of roots.
Starting with the root classes, a dependency graph is constructed by examining the compiled class file for a class, finding all of the classes it references, and then in turn examining those classes. The extent of the graph is determined by which packages are defined to be "inside" the graph and which are defined to be "outside" the graph. If a referenced class is in a package that is defined to be outside the graph, that class is not included in the graph, and none of classes that it references are examined. All of the root classes must be in packages that are defined to be "inside" the graph.
The inside and outside packages are specified by using the following options. Each of these options may be specified zero or more times. Some variations are illustrated in the Examples section of this page.
-skipoptions. This option can be specified zero or more times. If no
-inoptions are specified, the default is that all packages are considered to be inside packages. Note that the argument to
-inis a namespace, so none of its subpackages need to be specified as an argument to
If you use this option, you will likely need to use it multiple
times. For example, if your application classes are in the
com.corp.foo namespace, and you also use some classes in the
net.jini namespaces, then you
-in com.corp.foo -in org.apache.river -in net.jini
-inoptions, then each
-outnamespace should be a subspace of some
-innamespace. Note that the argument to
-outis a namespace, so none of its subpackages need to be specified as an argument to
If you use this option, you will likely need to use it multiple
times. For example, if you do not specify any
then all packages are considered inside the graph, including packages
defined in the Java 2 SDK that you typically want to exclude, so you
might exclude them by specifying:
-out java -out javaxAs another example, if you have specified
-in com.corp.foobut you don't want to include any of the classes in the
com.corp.foo.qanamespaces in the dependency graph, then you would specify:
-out com.corp.foo.test -out com.corp.foo.qa
-outrootoptions specified. When this option is set subdirectories of the specified directory are no longer considered as root for finding classes. When this option is not set, the default, the utility maintains the old behavior with respect to the semantics for the directories passed in and the
-pruneoption must be used. You are advised to set this option as there are some edge cases for which the old behavior won't work as expected, especially when no
-inoptions are set.
For example, you might exclude classes from the Java 2 SDK from the
dependency graph because you don't want to include them in your JAR file,
but you might be interested in knowing which classes from the Java 2 SDK
are referenced directly by the classes in your JAR file. The
-edges option can be used to display this information.
-showoptions are specified, the default is that all classes in the dependency graph are displayed (or all edge classes, if
-edgesis specified). Note that the argument to
-showis a namespace, so none of its subpackages need to be specified as an argument to
For example, to determine which classes from the Java 2 SDK your
application depends on, you might not specify any
options, but limit the output by specifying:
-show java -show javax
-showoptions, then each
-hidenamespace should be a subspace of some
-shownamespace. Note that the argument to
-hideis a namespace, so none of its subpackages need to be specified as an argument to
For example, to determine which non-core classes from the
net.jini namespace you use, you might specify:
-show net.jini -hide net.jini.core
com.corp.foo.Bar. This option should be used to generate output suitable as input to the
For more information on the
jar tool, see:
classesdirectory. Alternatively, if you have compiled from the source code, substitute
classesin the examples.)
The following example computes the classes required for a codebase JAR
file, starting with a smart proxy class and a stub class as roots, and
displays them in filename format. (A more complete example would include
additional roots for leases, registrations, events, and lookup service
attributes, and would exclude platform classes such as those in
java -jar install_dir/lib/classdep.jar \ -cp install_dir/classes \ org.apache.river.reggie.RegistrarProxy org.apache.river.reggie.RegistrarImpl_Stub \ -in org.apache.river -in net.jini \ -files
The following example computes the classes required for a classpath JAR
file, starting with all of the classes in a directory as roots, and
displays them in class name format. (A more complete example would exclude
platform classes such as those in
java -jar install_dir/lib/classdep.jar \ -cp install_dir/classes \ install_dir/classes/org/apache/river/reggie \ -in org.apache.river -in net.jini
The following example computes the
org.apache.river classes used
by a service implementation, and displays the
classes that are immediately referenced by those classes.
java -jar install_dir/lib/classdep.jar \ -cp install_dir/classes \ org.apache.river.reggie.RegistrarImpl \ -in org.apache.river \ -edges \ -show net.jini
The following example computes all of the classes used by a service
implementation that are not part of the Java 2 SDK, and displays the
classes that directly reference the class
java -jar install_dir/lib/classdep.jar \ -cp install_dir/classes \ org.apache.river.reggie.RegistrarImpl \ -out java -out javax \ -tell java.awt.Image
The following example computes all of the classes to include in
jini-ext.jar and displays them in filename format. Note
-prune options are needed
exclude classes from the dependency graph, and
prevent classes from being used as roots.
java -jar install_dir/lib/classdep.jar \ -cp install_dir/classes \ -in net.jini -out net.jini.core -in org.apache.river \ install_dir/classes/net/jini -prune net.jini.core \ -files
|Constructor and Description|
No argument constructor.
Constructor that takes command line arguments and fills in the appropriate fields.
|Modifier and Type||Method and Description|
Add an entry into the set of classes that dependencies are going to be computed on.
Add an entry into the set of package prefixes that are to remain hidden from processing.
Add an entry into the working set of package prefixes that will make up the working domain space.
Adds an entry into the set of package prefixes for which classes found through the specified root directories will be considered for dependency generation.
Add an entry into the set of package prefixes that will bypassed during dependency checking.
Adds an entry into the set of package prefixes for which classes found through the specified root directories, and that are part of the inside root namespace, will be skipped as part of the dependency generation.
Add an entry into the set of package prefixes that will be skipped as part of the dependency generation.
Add an entry into the set of directories to look under for the classes that fall within the working domain space as defined by the intersection of the following sets: inside,outside,prune,show, and hide.
Add an entry into the set of package prefixes that we want to display.
Add an entry into the set of classes that should be skipped during dependency generation.
Add an entry in to the set of classes whose dependents that lie with the inside set are listed.
Method that takes the user provided switches that logically define the domain in which to look for dependencies.
If true classnames will be separated using File.separator, else it will use dots.
Accessor method for the found dependencies.
Indicates whether computing the dependent classes as result of the last call to
Command line interface for generating the list of classes that a set of classes depends upon.
Set the classpath to use for finding our class definitions.
Determines whether to include package references that lie outside the declared set of interest.
Determines how to print out the fully qualified class names.
Controls whether the behavior for finding class files in the specified directories, if any, must be based on the old behavior (the default) or the new behavior that solves some of the problems with the old behavior.
Convenience method for initializing an instance with specific command line arguments.
Print out the usage for this utility.
public ClassDep(String cmdLine)
public String compute()
Whether a failure has occurred during computing the dependent classes
can be found out with a call to
public static void usage()
public void setClassPath(String classpath)
public void setFiles(boolean files)
trueit will use
.'s will be used. If not set the default is
public void addHides(String packagePrefix)
public void addInside(String packagePrefix)
public void setEdges(boolean edges)
If true edges will be processed as well, else
they will be ignored. If not set the default
Note: These edge classes must included in the classpath for this utility.
public void addOutside(String packagePrefix)
public void addPrune(String packagePrefix)
This method has no impact if the new behavior is effective for the interpretation of the root directories for finding class files to include for dependency checking.
public void setRootDirBehavior(boolean newBehavior)
public void addInsideRoot(String packagePrefix)
public void addOutsideRoot(String packagePrefix)
public void addShow(String packagePrefix)
public void addSkip(String packagePrefix)
public void addTells(String className)
public void addRoots(String rootName)
public void addClasses(String className)
public boolean getFiles()
public String getResults()
public boolean hasFailed()
compute()resulted in one or more failures.
truein case a failure has happened, such as a class not being found,
public void setupOptions(String args)
public static void main(String args)
Copyright 2007-2013, multiple authors.
Licensed under the Apache License, Version 2.0, see the NOTICE file for attributions.