This program is free software; you can redistribute it and/or modify
-it under the terms of version 3 of the GNU Lesser General Public
-License or later as published by the Free Software Foundation.
+
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.
Goal: simplify/speed up understanding the computer program code by
automatically visualizing its structure.
-JavaInspect is a Java library that primarily uses Java reflection to
-discover and visualize any part of Java program provided that
-classes to be visualised are available in the classpath.
+See example produced graphs for Sixth 3D - 3D engine project.
-JavaInspect currently has no GUI, configuration files, embedded
-scripting support, direct Maven or Ant integration. The only way to
-instuct Javainspect what to do is by using its Java API.
+JavaInspect can be used as a standalone commandline utility as well as
+java library. JavaInspect uses primarily Java built-in reflection to
+discover and visualize any part of Java program.
-To get JavaInspect into same classpath with your projecs I so far came
-up with 2 solutions:
+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.
-
-
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.
-
-
-
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
-bitmap graph in PNG format. By default on your Desktop directory.
+describes data to be visualized. Then launches GraphViz to generate
+bitmap graph in PNG or SVG format.
-Note: GraphViz is developed and tested so far only on GNU/Linux.
+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
+
+
+
+
+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
+
+
+
+
+Quick commandline usage help can be viewed by issuing
+
+
+javainspect --help
+
+
+
+
+
+
5 Usage
+
+
+JavaInspect can be controlled in 2 different ways:
+
+-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.
+
+
-Currently the only way to control JavaInspect is by using Java
-API. Simple Java based control/configuration code needs to be written
-for each project. I usually put such code into directories devoted for
+To get JavaInspect into same classpath with your projecs I so far came
+up with 2 solutions:
+
+
+
+
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.
+
+
+
+Simple Java based control/configuration code needs to be written for
+each project. I usually put such code into directories devoted for
JUnit tests. Because it needs not to be compiled/embedded into final
product or project artifact I'm just willing to visualize.
@@ -314,55 +574,40 @@ 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.
-
-
3.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
+
+// Create graphfinalClassGraphgraph = newClassGraph();
// Add some random object to the graph. GraphViz will detect Class from
@@ -378,6 +623,7 @@ graph.setKeepDotFile(true);
// Produce bitmap image titled "JavaInspect.png" to the user Desktop// directory
graph.generateGraph("JavaInspect");
+
@@ -385,7 +631,6 @@ graph.generateGraph("JavaInspect");
Note: if desired, more compact version of the above:
// Create graph
-finalClassGraphgraph = newClassGraph();
-
-// 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");
-
-GraphViz - shall be installed on the computer.
+Note: Because this is side project (and I have many of them) I can
+only contribute few hours per year at average. Any help is welcome. A
+LOT of cool ideas could be implemented. For intstance:
-
-On Ubuntu/Debian use:
-
-
+
+
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.
-
sudo apt-get install graphviz
-
-
+
BUG: Orphaned class removal does not work always. There are many
+bugs and corner cases to find and fix still.
+
+
BUG: Code is not very readable. Document and refactor for better
+maintainability.
+
+
FEATURE: Create installable DEB package.
+
+
Submit it to some Debian developer for integration or become
+Debian package maintainer.
+
+
+
FEATURE: Make it modular. That is: central part, an application
+model could be standalone and serializable.
+
+
+
There could be multiple ways to acquire model:
+
+
By introspecting application via Java reflections (current mode
+of operation).
+
By parsing java source. (unfinished)
+
+
+
There could be ways to manipulate model:
+
+
Store/load/compare.
+
Trim uninteresting parts.
+
Highlight important parts.
+
+
+
There could be multiple ways to render model:
+
+
PNG/SVG (currently implemented)
+
PlantUML (TODO)
+
Interactive 3D visualization (TODO)
+
+
+
+
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.
+
+
FEATURE: Possibility to visualize structure and data from JVM
+snapshot.
+
+
FEATURE: Possibility to attach to remote process to visualize
+data/structure using JVM debug port and mechanism.
+
+
FEATURE: Possibility to attach to JVM using JVM agent.
+
+
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.
+
+
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.
+
+
FEATURE: Configurable maven plugin to generate graphs as part of the
+project build/release process.
+
-
-
6 TO DO
-
+
+
7 See also
+
+
+Similar or alternative solutions:
+
-
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.
-
++
++
