Unusual tip to find refactoring hot-spot

Disclaimer: This post contains generalization based on my experience, it may or may not be applicable in every state of code-base resembling this situation.

Most of you have probably been through this list of smells to refactoring. In Recent refactoring sessions I discovered a new (at least unusually new) way to identify "hot-spot" needing refactoring.

This might be in turn related to some other smells (like most of them), but here it is:

- A (set of) source file with significantly more revisions compared to it's dependencies demands refactoring.

The obvious question here is why?
- Number of revisions for a source file indicate that it is being modified more frequently than it should. There can be many reasons why a source file is being modified among:

• Imperative requirements change or
  
• A source file that tries to do so much than it should

Now, requirements change is something very common in everyday life. But generally speaking ( opps! ), Not all requirements ask for a significant change in control flow but data. Depending on the domain, you can externalize the portions which keep changing to helper classes or configurations.

A source file trying to do more than it could is always a problem and is generally perceived as 'God module', it's time to slice it down.

So next time you feel like hunting for bad code, look at the revisions and you will have hint where to start. Good hunting.

PS: Note that I've deliberately generalized this to 'source files' and not the configurations.

How to find which jar file contains your class at 'runtime'

If you ever wanted to know which jar your class belongs, or wanted to access the meta-information from that jar file (such as certs from Manifest.mf etc.), here's how you can do it.

    public URL getJarURL() {
       URL clsUrl = getClass().getResource(getClass().getSimpleName() + ".class");
       if (clsUrl != null) {
           try {
               URLConnection conn = clsUrl.openConnection();
               if (conn instanceof JarURLConnection) {
                   JarURLConnection connection = (JarURLConnection) conn;
                   return connection.getJarFileURL();
               }
           }
           catch (IOException e) {
               throw new RuntimeException(e);
           }
       }
       return null;
   } 

This would work in most of the enterprisely Java environment (unless your classloader is hacked by some stupid framework in between), not sure if this would be valid under OSGi container.

Why in the name of programming I need to write such trivial hacks? O Java Module system (JSR277), I await you.

Note: This is the simplest way I could write, if you know smarter way, feel free to comment here.