I wonder if Andy has seen this.

Updated (11/02/07) : Please note the responses from Alberto and Bob attached to this post. They’ve offered some assurance that Crap4J does not transmit any code to their servers, and that the licensing snafu was due to a simple oversight. They also resolve to correct the licensing agreements. Thank you, Alberto and Bob! : End Update

I went to install the Crap4J Eclipse plug-in. As part of this plug-in, there are four separate features, and I happened to actually read the license agreement for each of them. In a nutshell, for three of the features (Agitair JUnit Runner, Agitair JUnit4 Suport, and Public API for Generated Tests), the license agreement states that the software is experimental and primarily for academic, research, and open source use. But that’s not the alarming part. It also says that it transmits your code over the open internet to be analyzed on non-secure Agitair computers shared by multiple users. Here’s the exact text:

THIS SOFTWARE IS INTENDED PRIMARILY FOR ACADEMIC, RESEARCH, AND OPEN SOURCE
USE. WHILE COMMERCIAL USE IS ALLOWED, PLEASE BE AWARE THAT YOUR CODE
IS TRANSMITTED OVER THE OPEN INTERNET AND ANALYZED ON NON-SECURE
COMPUTERS SHARED BY MULTIPLE USERS.

I don’t like that much, and it seems a bit sneaky to hide that rather important note in a license agreement that I doubt many folks read. There should be a more noticeable disclaimer somewhere. Also, I found no such notice in the Ant Task distribution (in fact, couldn’t find a license agreement included at all). But that’s not saying the Ant Task does or does not transmit your code.
I don’t know the internal behavior of Crap4J. Maybe it doesn’t send your code anywhere. But the license agreement indicates that Crap4J does, or at the very least, that they have the right to do so. Maybe, giving them the benefit of the doubt, they didn’t fully review the license agreement, and aren’t aware of what it says. Either way, the fact that this important note is buried within a license agreement without any other public disclaimer is very alarming and deceiving.

JarAnalyzer has always had the ability to create a dot-compliant output file that could be used with GraphViz to generate a component diagram. In the past, this had always been done using the DOTSummary class. Unfortunately, this meant that if you wanted to generate output files in both xml and dot, you had to run JarAnalyzer twice. Now, thanks to a stylesheet that I graciously stole from JDepend and modified to work with JarAnalyzer, there’s a new way to generate a dot-compliant output file that is much nicer than what you’ll get when using DOTSummary. Plus, you only have to run JarAnalyzer once, then apply two stylesheets to the xml file generated to get both the html report and component diagram.

In addition to being a bit more efficient, it’s also cleaner. The old component diagram is shown at left on top, while the new component diagram using the stylesheet is shown at bottom left. The stylesheet avoids the confusion where DOTSummary changed the name of the .jar file and stripped off the .jar extension. As seen on the diagrams, a .jar file named bill.jar now actually appears as bill.jar on the component diagram, not bill.

The new stylesheet isn’t part of the JarAnalyzer distribution…yet, but you can download the stylesheet. To run JarAnalyzer as part of your Ant build script and get both the html and component diagram output, drop the stylesheet in the directory containing JarAnalyzer (the same directory with jaranalyzer.xsl), and modify your build script similar to the following (you need GraphViz installed to run dot):

<target name="dotanalyzerapp.new" depends="bundle">
   <taskdef name="jaranalyzer"
             classname="com.kirkk.analyzer.textui.JarAnalyzerTask">
       <classpath>
           <pathelement path="${buildlib}/jaranalyzer-1.2.jar"/>
           <pathelement path="${buildlib}/lib/bcel-5.2.jar"/>
           <pathelement path="${buildlib}/lib/jakarta-regexp-1.3.jar"/>
           <pathelement path="${buildlib}/lib"/>
       </classpath>

   </taskdef>

   <jaranalyzer srcdir="${buildstats}"
                destfile="${buildstats}/appdependencies.xml"
                summaryclass="com.kirkk.analyzer.textui.XMLUISummary"/>

   <style in="${buildstats}/appdependencies.xml"
                    out="${buildstats}/appdependencies.html"
                    style="${buildlib}/jaranalyzer.xsl">
   </style>

   <style in="${buildstats}/appdependencies.xml"
                    out="${buildstats}/appdependencies.grph"
                    style="${buildlib}/jaranalyzer2dot.xsl">
   </style>

   <exec executable="dot" >
       <arg line="-Tpng -Nshape=box -Nfontsize=30 -Nwidth=1.5
              -Nheight=1.25<br></arg> ./buildstats/appdependencies.grph
              -o ./buildstats/appdependencies.png">
   </exec>

 </target>

I’ve updated JarAnalyzer to correct some of the problems reported when analyzing applications written on J2SE 5.0. The issues were primarily surrounding the use of Generics. If you’ve been experiencing any of the following problems when running JarAnalyzer 1.1, upgrading to JarAnalyzer 1.2 should make them go away and put you back on track.

• You receive the following error at the console: Visiting non-standard Signature object. The fix required an upgrade to BCEL 5.2.
• The xml output lists classes as Unresolved Dependencies. This problem was due to how JarAnalyzer strips the classname from the package the class belongs to.

A few other bug fixes and enhancements also found their way into version 1.2.

• Used System properties file separator to increase portability across operating systems.
• Updated filter.properties file to ignore packages you typically don’t want reported as Unresolved Dependencies. This can easily be modified before running JarAnalyzer if you want these to show in the output.

You can download the most current version of JarAnalyzer from the JarAnalyzer home.