Java source refactoring of 7000 references

Question

I need to change the signature of a method used all over the codebase.

Specifically, the method void log(String) will take two additional arguments (

Answer 1

I agree with Seanizer's answer that you want a tool that can parse Java. That's necessary but not sufficient; what you really want is a tool that can carry out a reliable mass-change.

To do this, you want a tool that can parse Java, can pattern match against the parsed code, install the replacement call, and spit out the answer without destroying the rest of the source code.

Our DMS Software Reengineering Toolkit can do all of this for a variety of languages, including Java. It parses complete java systems of source, builds abstract syntax trees (for the entire set of code).

DMS can apply pattern-directed, source-to-source transformations to achieve the desired change.

To achieve the OP's effect, he would apply the following program transformation:

 rule replace_legacy_log(s:STRING): expression -> expression
    " log(\s) " -> " log( \s, \class\(\), \method\(\) ) "

What this rule says is, find a call to log which has a single string argument, and replace it with a call to log with two more arguments determined by auxiliary functions class and method.

These functions determine the containing method name and containing class name for the AST node root where the rule finds a match.

The rule is written in "source form", but actually matches against the AST and replaces found ASTs with the modified AST.

To get back the modified source, you ask DMS to simply prettyprint (to make a nice layout) or fidelity print (if you want the layout of the old code preserved). DMS preserves comments, number radixes, etc.\

If the exisitng application has more than one defintion of the "log" function, you'll need to add a qualifier:

... if IsDesiredLog().

where IsDesiredLog uses DMS's symbol table and inheritance information to determine if the specific log refers to the definition of interest.

Answer 2

Do you really need to change the calling code and the method signature? What I'm getting at is it looks like the added parameters are meant to give you the calling class and method to add to your log data. If the only requirement is just adding the calling class/method to the log data then Thread.currentThread().getStackTrace() should work. Once you have the StackTraceElement[] you can get the class name and method name for the caller.

Answer 3

Try refactor using intellij. It has a feature called SSR (Structural Search and Replace). You can refer classes, method names, etc for a context. (seanizer's answer is more promising, I upvoted it)

Answer 4

I think that there are several steps to dealing with this, as it is not just a technical issue but a 'situation':

1. Decline to do it in short order due to the risk.
2. Point out the issues caused by not using standard frameworks but reinventing the wheel (as Paul says).
3. Insist on using Log4j or equivalent if making the change.
4. Use Eclipse refactoring in sensible chunks to make the changes and deal with the varying defaults.

I have used Eclipse refactoring on quite large changes for fixing old smelly code - nowadays it is fairly robust.

Answer 5

If the class and method name are required for "where did this log come from?" type data, then another option is to print out a stack trace in your log method. E.g.

public void log(String text)
{
   StringWriter sw = new StringWriter();
   PrintWriter pw = new PrintWriter(sw, true);
   new Throwable.printStackTrace(pw);
   pw.flush();
   sw.flush();
   String stackTraceAsLog = sw.toString();
   //do something with text and stackTraceAsLog
}

Answer 6

I would search and replace log( with log(@class, @methodname,

Then write a little script in any language (even java) to find the class name and the method names and to replace the @class and @method tokens...

Good luck