JPragma Blog

Today’s very short post is about ways to identify technical debt and how to find components/classes that require immediate attention.

1. Files that have a large number of git commits (they are changed often). These files are dependency magnets, they most likely violate “Open-close principle” and “Single responsibility principle”. Create a report by running:

   # list repo files with their total number of commits
   git log --name-only --pretty=format: | sort | uniq -c | sort -nr > git_stats.txt
   

2. SonarQube provides pretty good reports showing the complexity and test coverage of your classes

There are some very useful command line options you can specify when executing maven tests:

-Dtest=[testname], this allows selective execution of unit tests, instead of running them all. [testname] might be full class name, class name without package, or even wildcard.

-Dsurefire.useFile=false, this will force surefire plugin to write failing test info to stdout instead of file in target/surefire-reports/. Can be a huge time saver.

If your server is running in one timezone, but you want to have log messages be printed using different timezone, here is a simple solution:

1. Add log4j extras to project classpath (maven GAV is log4j:apache-log4j-extras:1.0)
2. In log4j.xml use EnhancedPatternLayout, specifying required timezone for logging purposes (see example below for EST TZ)

<appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender">
    <param name="Threshold" value="TRACE" />
    <layout class="org.apache.log4j.EnhancedPatternLayout">
        <param name="ConversionPattern" value="%d{ISO8601}{EST} %-5p [%t][%c:%M(%L)] %m%n" />
    </layout>
</appender>

In this example, log messages will be printed using EST regardless of your server timezone.

In many projects, especially big ones, developed over several years, there is a lot unused code. Cleaning up projects and deleting such unused code is important.

• Eclipse can detect unused methods and variables.
• PMD (and PMD maven plugin) can also do this and even be integarated into CI process.
• Eclipse Core Tools plugin can find unused classes (see description here).

Unfortunately all above methods will mark code invoked by reflection (e.g. using IoC container such as Spring) as unused. At the same time garbage code that was left behind together with its unit test won’t be detected.

I see only one way to detect such obsolete code – run the system for a while through all typical scenarios and collect statistics on loaded classes, invoked methods, etc. Of course report generated using this technique can be only considered as a hint and manual verification is required.
Proper solution should probably be done using AOP, instrumenting code either during compile or load time. There is however quick and dirty way that archives similar results.

1. Run your app with -verbose:class option (send standard output to file in addition to console using | tee <filename>)
   Example:
   $ export MAVEN_OPTS="$MAVEN_OPTS -verbose:class"
$ mvn clean jetty:run | tee jetty.log
2. Execute all typical scenarios of your application
3. From generated log file create sorted list of your project classes used in executed scenarios:
   $ grep "\[Loaded.*com.jpragma" jetty.log | awk '{print $2}' | sort | uniq -u > loaded_classes.txt
4. Create sorted list of your compiled project classes:
   $ find target/classes/ -name *.class | sed 's/target\/classes\/\///g' \
| sed 's/.class//g' | tr -s '/' '.' \
| sort > declared_classes.txt
5. Compare two txt files finding all classes that declared but not used:
   $ diff loaded_classes.txt declared_classes.txt | grep ">"

Note: This is a copy from my old blog posted in 2007. Some things mentioned here have been changed since then.

Groovy is a great scripting language intimately integrated with Java. Being able to leverage any code written in Java and at the same time having all the advantages of dynamic programming language, makes it an excellent choice for tasks such as file management, build systems and testing.

JMeter is an open source load test tool. It supports many protocols (HTTP, FTP, JMS and others) out-of-the-box.

Many times I found myself in situation when I wanted to run load test against stand-alone Java components or against an application that uses proprietary binary TCP based protocol. Groovy would be an excellent choice for this task. Some work on integrating JMeter and Groovy was done by Alexandru Popescu, however the project is not available to the public yet. Then I discovered that there is an indirect support for groovy in JMeter itself. JMeter supports BSF, which is an abstraction layer on top of many scripting languages including groovy. BSF distribution that comes with JMeter actually has some glitch in groovy support, but after upgrading to the latest version of bsf.jar it was very easy to start writing JMeter scripts in groovy.

Here the steps I followed:

1. download latest groovy binaries from http://groovy.codehaus.org/
2. copy groovy-all-1.0.jar to jmeter/lib directory
3. download latest bsf binaries from http://jakarta.apache.org/bsf/ (I was using version 2.4.0)
4. replace bsf-2.3.0.jar in jmeter/lib with bsf.jar from the version you just downloaded
5. start jmeter
6. create BSF Sampler and specify “groovy” as a scripting language (see screenshot below)
7. type your groovy script and run it

This method is far from being perfect. It actually monitors how much time it takes to execute the script itself, but in most cases you’d like to specify exactly when to start counting execution time [results.sampleStart(); results.samplePause(); results.sampleResume(); results.sampleEnd();]
I hope Alexandru will make his project available soon, or may be I’ll find some time to create more sophisticated JMeter Groovy plug-in.

Another issue is how to transfer data between several scripts. Let’s say you’d like to create 1st script that establishes TCP connection; 2nd that sends proprietary login message and gets back some security token; 3rd that sends some business message (using the same TCP connection and providing the token) and 4th that just disconnects. How to transfer Socket and Token objects between scripts? Well, you can use ThreadLocal. Following code snippet defines ThreadLocalStorage class that can be used from the scripts (isn’t it great that you can just call Java from Groovy?) to save and retrieve any data:

package com.jpragma.utils;

import java.util.HashMap;

public class ThreadLocalStorage {
  private static ThreadLocal storage = new ThreadLocal() {
    protected Object initialValue() {
      return new HashMap();
    }
  };
  
  public static Object get(String name) {
    HashMap vars = (HashMap) storage.get();
    return vars.get(name);
  }
  
  public static void set(String name, Object value) {
    HashMap vars = (HashMap) storage.get();
    vars.put(name, value);
  }
}

Just package it as a jar file and put into jmeter/lib directory. Now you can write your scripts like this:

Connect:

import com.jpragma.utils.ThreadLocalStorage

def socket = new Socket("localhost", 18012);
def iStream = new DataInputStream(socket.getInputStream());
def oStream = new DataOutputStream(socket.getOutputStream());

ThreadLocalStorage.set('mySocket', socket)
ThreadLocalStorage.set('myInStream', iStream)
ThreadLocalStorage.set('myOutStream', oStream)

return "success"

Echo Message

import com.jpragma.utils.ThreadLocalStorage

def iStream = ThreadLocalStorage.get('myInStream')
def oStream = ThreadLocalStorage.get('myOutStream')

def str = "My String"
oStream.writeInt(str.length())
oStream.write(str.bytes)

def msgSize = iStream.readInt()
def buf = new byte[msgSize]
iStream.readFully(buf)
def responseStr = new String(buf)

if (str == responseStr)
    return "success"
else
    return "failure"

Disconnect

import com.jpragma.utils.ThreadLocalStorage

def socket = ThreadLocalStorage.get('mySocket')
if (socket != null) {
    socket.close()
}
return "success"