This program is free software: you can redistribute it and/or modify
it under the terms of the GNU Lesser General Public License as
published by the Free Software Foundation, either version 3 of the
-License, or (at your option) any later version.
-
-JavaInspect currently has no GUI, configuration files, embedded
-scripting support, direct Maven or Ant integration. See usage to learn
-how to instuct Javainspect what to do.
+JavaInspect currently has no graphical user interface, configuration
+files, embedded scripting support, direct Maven, Gradle or Ant
+integration. See usage to learn how to instuct Javainspect what to do.
After discovering application structure and optionally filtering out
unimportant parts, JavaInspect produces GraphViz dot file that
-describes data to be visualized. Then launches GraphViz to generate
+describes data to be visualized. Then launches GraphViz to generate
bitmap graph in PNG or SVG format.
-
-By default on your Desktop directory when operated in library mode or
-current working directory when operated as standalone commandline
-application.
-
-
Notes:
-
JavaInspect is developed and tested so far only on GNU/Linux.
-
+On Ubuntu/Debian GraphViz can be installed using:
+
+
+
sudo apt-get install graphviz
+
-
-
4.1 usage as commandline utility
-
-To enable commandline support, (study and) execute script:
+To use JavaInspect via Java API, no further installation is
+needed. JavaInspect will be embedded into your project as dependency.
+This is described in usage via Java API. It will expect GraphViz to be
+available in the system.
+
+
+
+To use JavaInspect as a commandline tool, JavaInspect source
+repository has to be cloned locally: See Source code.
+
+
+
+Then study and execute installation script:
commandline launcher/install
+
+
+
+After installation, new commandline tool should be available
+
+
+javainspect
+
-Warning: It was tested only on Debian Stretch linux.
+Quick commandline usage help can be viewed by issuing
+
+javainspect --help
+
+
+
+
+
5 Usage
+
-Available commandline arguments:
+JavaInspect can be controlled in 2 different ways:
--j (existing files)…
- JAR file(s) to render.
-
--n (mandatory, string)
- Graph name.
-
-–debug
- Show debug info.
-
--k
- Keep dot file.
-
--h
- Hide orphaned classes.
-
--w (one to many strings)…
- Whitelist glob(s).
-
--b (one to many strings)…
- Blacklist glob(s).
-
--d (existingdirectory)
- Target directory. Default is current directory.
-
--t (options: png, svg)
- Target image type. Default is: svg.
-
-
-
-
-
4.2 usage via Java API
-
+-j (existing files)…
+ JAR file(s) to render.
+
+-c (existing directories)…
+ Classpath directories
+
+-n (string)
+ Graph name. (default: "graph")
+
+–debug
+ Show debug info.
+
+-h, –help
+ Show commandline usage help.
+
+-k
+ Keep dot file.
+
+-ho
+ Hide orphaned classes.
+
+-w (one to many strings)…
+ Whitelist glob(s).
+
+-b (one to many strings)…
+ Blacklist glob(s).
+
+-r (one to many strings)…
+ root class(es).
+
+-d (existing directory)
+ Target directory. Default is current directory.
+
+-t (options: png, svg)
+ Target image type. Default is: svg.
+
+
+
+
+
5.1.2 Specifying classes to render
+
+
+Normal Java application has immense complexity. In addition to code
+that was directly written by particular project developers, lots of
+functionality is typically added as frameworks or libraries to the
+project. In addition there is significant Java standard library.
+
+
+
+Because JavaInspect uses reflection, it does not easily distinguish
+between those. In normal situation you would rather want to visualize
+only code that was developed specifically for your project and leave
+frameworks like Spring etc. out. If you visualize all classes that are
+possibly reachable from you project, you will easily get huge and
+incomprehensible graph.
+
+
+
+JavaInspect can digest compiled Java classes in 2 modes:
+
+
+
Provide list of Jar files. Use -j option.
+
Provide list of filesystem directories that can be used as
+classpath root. Use -c option.
+
+
+
+Currently JavaInspect uses following algorithm to add classes to
+rendered graph:
+
+
+
+
All classes that were found in Jar files are added to graph by default.
+
None of the classes that were found in filesystem directories are
+added to the graph by default (unless explicitly referenced). (TODO:
+for consistency it would be better to add them too by default)
+
If whitelist is specified (-w option) everything that is not
+matched by whitelist pattern(s) will be removed from the graph.
+
If blacklist is specified (-b option) everything that is matched
+by blacklist pattern(s) will be removed from the graph.
+
Root classes can be specified using -r option. Root classes will
+be added to the graph. JavaInspect will then try to recursively
+discover all classes that were referenced by root class and add
+those also to the graph.
+
+
+
+
+
+
+
5.2 Usage via Java API
+
Requires that classes to be visualised are available in the classpath.
@@ -404,15 +554,13 @@ up with 2 solutions:
-
Add JavaInspect library in your project as a dependency.
-
+
Add JavaInspect library in your project as a dependency.
Create new Java project for the purpose visualizing your other
projects and include JavaInspect and your projecs binary artifacts
(Jar's) into new project classpath. Built binary Jar's (with no
source code) are sufficient because JavaInspect operates via
-reflection.
-
+reflection.
@@ -426,71 +574,55 @@ product or project artifact I'm just willing to visualize.
Control code in general does the following:
-
Create graph object.
-
+
Create graph object.
Java reflection/classloaders does not provide mechanism for
discovering all classes under given package. Therefore you need to
-declare at least some classes to be added to the graph by:
-
-
Manually adding individual classes to the graph.
-
-
and/or: Let GraphViz recursively scan and parse specified
-directories with Java source code files to discover class names.
-
-
For every class added to the graph, GraphViz will recursively
-inspect it and add all referecned classes to the graph as well.
-
-
-
+declare at least some classes to be added to the graph by manually
+adding individual classes to the graph. For every class added to
+the graph, GraphViz will recursively inspect it and add all
+referecned classes to the graph as well.
Graphs easilly get very big and complex so optionally we filter
-important code using classname wildcards patterns based blacklist
-and/or whitelist.
-
+important code using classname glob patterns based blacklist and/or
+whitelist.
Optionally we can tune some rendering parameters like:
Possibility to remove orphaned classes (classes with no
-references) from the graph.
-
+references) from the graph.
Specify target directory for generated visualization
-files. (Default is user desktop directory)
-
-
Keep intermediate GraphViz dot file for later inspection.
-
-
-
-
Render graph.
-
+files. (Default is current directory)
+
Keep intermediate GraphViz dot file for later inspection.
+
+
Render graph.
-
-
4.2.1 example 1: individually picked objects
-
+
+
5.2.1 Example 1: individually picked objects
+
This example demonstrates generating of class graph from hand picked
classes and visualizing GraphViz itself.
-
-// Create graph
-final ClassGraph graph = new ClassGraph();
+// Create graph
+finalClassGraphgraph = newClassGraph();
-// Add some random object to the graph. GraphViz will detect Class from
-// the object.
+// Add some random object to the graph. GraphViz will detect Class from
+// the object.
graph.add(graph);
-// Also add some random class to the graph.
-graph.add(Utils.class);
+// Also add some random class to the graph.
+graph.add(Utils.class);
-// Keep intermediary GraphViz DOT file for reference.
-graph.setKeepDotFile(true);
+// Keep intermediary GraphViz DOT file for reference.
+graph.setKeepDotFile(true);
-// Produce bitmap image titled "JavaInspect.png" to the user Desktop
-// directory
-graph.generateGraph("JavaInspect");
+// Produce bitmap image titled "JavaInspect.png" to the user Desktop
+// directory
+graph.generateGraph("JavaInspect");
@@ -499,9 +631,8 @@ graph.generateGraph("JavaInspect");
Note: if desired, more compact version of the above:
-
-
new ClassGraph().add(randomObject, RandomClass.class)
- .setKeepDotFile(true).generateGraph("JavaInspect");
+
// Create graph
-final ClassGraph graph = new ClassGraph();
-
-// Recursively scan current directory for Java source code and attempt
-// to detect class names from there to be added to the graph.
-graph.addProject(".");
-
-// Blacklist example classes from being shown on the graph
-graph.blacklistClassPattern("eu.svjatoslav.inspector.java.structure.example.*");
-
-// do not show single classes with no relationships on the graph
-graph.hideOrphanedClasses();
-
-// Produce bitmap image titled "JavaInspect full project.png" to the
-// user Desktop directory.
-graph.generateGraph("JavaInspect full project");
-
Note: Because this is side project (and I have many of them) I can
@@ -635,24 +710,19 @@ LOT of cool ideas could be implemented. For intstance:
BUG: Should not hide references if there are too many of them to
classes if referring classes are not visible anyway because of
blacklist/whitelist rules. Basically reference counting should
-exclude not visible classes.
-
+exclude not visible classes.
BUG: Orphaned class removal does not work always. There are many
-bugs and corner cases to find and fix still.
-
+bugs and corner cases to find and fix still.
BUG: Code is not very readable. Document and refactor for better
-maintainability.
-
+maintainability.
FEATURE: Create installable DEB package.
Submit it to some Debian developer for integration or become
-Debian package maintainer.
-
-
-
+Debian package maintainer.
+
FEATURE: Make it modular. That is: central part, an application
model could be standalone and serializable.
@@ -661,113 +731,81 @@ model could be standalone and serializable.
There could be multiple ways to acquire model:
By introspecting application via Java reflections (current mode
-of operation).
-
FEATURE: Implement (or integrate existing java parser
+https://javaparser.org/) to be able to produce code visualizations
+based on source code (in addition to current reflection based
+approach).
FEATURE: Visualize also concrete field values so it could be used as
-ultra cool runtime logging/debugging framework.
-
+ultra cool runtime logging/debugging framework.
FEATURE: Possibility to visualize structure and data from JVM
-snapshot.
-
+snapshot.
FEATURE: Possibility to attach to remote process to visualize
-data/structure using JVM debug port and mechanism.
-
+data/structure using JVM debug port and mechanism.
-
FEATURE: Possibility to attach to JVM using JVM agent.
-
+
FEATURE: Possibility to attach to JVM using JVM agent.
-
FEATURE: Possibility to inspect graphs in 3D using Sixth 3D engine.
-
+
FEATURE: Possibility to inspect graphs in 3D using Sixth 3D engine.
FEATURE: Possibility to select classes/fields/values to be
visualized in some graph query language. For greater flexibility in
-comparison to currently supported glob syntax.
-
+comparison to currently supported glob syntax.
FEATURE: Add option to control JavaInspect via JSON or XML config
file. For example different graphs for given project could be
defined once in plain text config, possibly with the aid of some
interactive utility. Then defined graphs could be updated as part of
-project build or release process.
-
+project build or release process.
FEATURE: Configurable maven plugin to generate graphs as part of the
-project build/release process.
-