The Power of Visualization
The Power of Visualization
It’s always interesting to use DepAn on a new body of code. I’m constantly amazed at the power of visualization to expose hidden details. The human eye is well tuned to pick-up on subtle variations, and DepAn’s rich rendering capabilities can help you see details that are invisible when scanning source code. In this case study, DepAn readily exposed some dead code in the the Guava libraries.
During a recent demo of DepAn, I fairly randomly decided to perform a Java Analysis on the Guava libraries. These are a collection of ~500 Java utility class that Google makes available. My expectation was that the Guava libraries would have some instructive examples of good code structure. These classes are very well w1ritten, and receive intense scrutiny from top-tier software engineers.
There’s a lot of code here, and even DepAn has challenges displaying the entire set of software elements in an illuminating manner. However, the package com.google.common.xml has only one class with 12 software elements (nodes). With the default FRLayout, DepAn’s View Editor generates a pretty little picture for our review:
Initial DepAn layout for the XML Escapers package.
In this little diagram, notice how the XmlEscaper.XML_ESCAPER node stands out as very distinctive. Not only is the XML_ESCAPER node yellow, it is also the only circle (i.e. member field) that is yellow. That yellow indicates that XML_ESCAPER has an in-degree of 2, and other similar fields (XML_CONTENT_ESCAPER and XML_ATTRIBUTE_ESCAPER) have a in-degree of three.
With a little re-arrangement, the lack of parallel structure is more obvious:
Manual DepAn layout for the XML Escapers package, showing the lack of parallelism for the different XML escaper instances.
For some reason, XML_ESCAPER is lacking the xmlEscaper() method (i.e. rounded squares) that would parallel the structure of the other escaper fields. A little investigation into the source code reveals that XML_ESCAPER is unused internally and inaccessible externally. It is dead code.
A pull-request to remove field was been sent to the Guava maintainers, and produced this curious response:
So this is actually some deprecated code that we have internally, and is publicly accessible for our internal users (the method is deprecated).
Usually we’re able to strip out that stuff, but since it’s being constructed in a static block, it’s a little more difficult. Since it’s not hurting anything, I’m inclined to leave it as-is.
Once again, DepAn’s ability to visualize complex interdependencies demonstrates its effectiveness at software analysis. The git logs suggest that Escapers have had a mixed history in the Guava libraries, and they were added and removed around release 12.0. During this process, it appears that an old bit of legacy code was left in but abandoned. The abandoned code meant that some of the dependencies were inconsistent, and DepAn makes it simple for us mortals to see these inconsistencies.