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 (Class c, String methodName), which need to be provided by the caller, depending on the method where it is called. I can't simply pass null or similar.
To give an idea of the scope, Eclipse found 7000 references to that method, so if I change it the whole project will go down. It will take weeks for me to fix it manually.
As far as I can tell Eclipse's refactoring plugin of Eclipse is not up to the task, but I really want to automate it.
So, how can I get the job done?
Great, I can copy a previous answer of mine and I just need to edit a tiny little bit:
I think what you need to do is use a source code parser like javaparser to do this.
For every java source file, parse it to a CompilationUnit, create a Visitor, probably using ModifierVisitor as base class, and override (at least) visit(MethodCallExpr, arg). Then write the changed CompilationUnit to a new File and do a diff afterwards.
I would advise against changing the original source file, but creating a shadow file tree may me a good idea (e.g. old file: src/main/java/com/mycompany/MyClass.java, new file src/main/refactored/com/mycompany/MyClass.java, that way you can diff the entire directories).
Eclipse is able to do that using Refactor -> Change Method signature and provide default values for the new parameters.
For the class parameter the defaultValue should be this.getClass() but you are right in your comment I don't know how to do for the method name parameter.
IntelliJ IDEA shouldn't have any trouble with this.
I'm not a Java expert, but something like this could work. It's not a perfect solution (it may even be a very bad solution), but it could get you started:
Change the method signature with IntelliJ's refactoring tools, and specify default values for the 2 new parameters:
c: self.getClass()
methodName: Thread.currentThread().getStackTrace()[1].getMethodName()
or better yet, simply specify null as the default values.
I think that there are several steps to dealing with this, as it is not just a technical issue but a 'situation':
Decline to do it in short order due to the risk.
Point out the issues caused by not using standard frameworks but reinventing the wheel (as Paul says).
Insist on using Log4j or equivalent if making the change.
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.
Maybe I'm being naive, but why can't you just overload the method name?
void thing(paramA) {
thing(paramA, THE_DEFAULT_B, THE_DEFAULT_C)
}
void thing(paramA, paramB, paramC) {
// new method
}
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.
If the lines you need replaced fall into a small number of categories, then what you need is Perl:
find -name '*.java' | xargs perl -pi -e 's/log\(([^,)]*?)\)/log(\1, "foo", "bar")/g'
I'm guessing that it wouldn't be too hard to hack together a script which would put the classname (derived from the filename) in as the second argument. Getting the method name in as the third argument is left as an exercise to the reader.
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)
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.
Il fact your problem is not to use a click'n'play engine that will allow you to replace all occurences of
log("some weird message");
by
log(this.getClass(), new Exception().getStackTrace()[1].getMethodName());
As it has few chances to work on various cases (like static methods, as an example).
I would tend to suggest you to take a look at spoon. This tool allows source code parsing and transformation, allowing you to achieve your operation in a -obviously code based- slow, but controlled operation.
However, you could alos consider transforming your actual method with one exploring stack trace to get information or, even better, internally use log4j and a log formatter that displays the correct information.
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
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
}
Related
In org.eclipse.cdt.codan.internal.core.CodanRunner I found the following code:
CheckersRegistry chegistry = CheckersRegistry.getInstance();
chegistry contains a lot of Checkers, including a ReturnChecker.
...
for (IChecker checker : chegistry) {
...
((IRunnableInEditorChecker) checker).processModel(model, context);
...
}
This code eventually calls the ReturnChecker's method to search in the statements in a function body (IASTFunctionDefinition) for a return statement. If that statement is missing, reportNoRet() is called. The editor marks the function with "No return, in function returning non-void".
Is there a way to override this ReturnChecker (or any other of the checkers) so that it only in some cases "reportNoRet" is not called? I also like to know if there is a way to add checkers (I couldn't find an extension point).
You could try to extend the class to perform your own checks, but the basic checker will be always used. Maybe it would be better to create a new set of checkers for your language extension. Take a look here, you find how to add new checkers.
You can definitely add new checkers. The extension point, as mentioned in #greywolf82's link, is org.eclipse.cdt.codan.core.checkers.
I'm not aware of a way to modify ReturnChecker's behaviour in a more granular way that disabling specific problem types entirely. You're probably better off disabling ReturnChecker, and copying its code into your own checker with the desired modifications. (The disablement can also be done declaratively using the org.eclipse.cdt.codan.core.checkerEnablement extension point.)
I have this code here:
assertThat( new Whatever(TestPerson.class, ReadOnly.class) .foo(), is(bar));
in a unit test. I figured that I will need multiple different such calls, which only differ in the second argument. So I thought to create a helper method so that I can do
assertThat( makeFor(ReadOnly.class) .foo(), is(bar));
I wanted to use the refactoring capabilities of IntelliJ for that, but when select new Whatever.... .class) and go for Extract method both parameters will be "hardcoded" within the the generated method. But I want only the first parameter to be hardcoded, and the second one to be a parameter for the new method.
Now I am wondering: is there an elegant way to do that with some magic IntelliJ refactoring actions? Without me manually adding the parameter after extracting that method?
You have to combine two refactoring actions and learning different combination is the key to save and fast refactoring.
Two different combinations comes into my mind:
You use the extract method (alt+ctrl+m) refactoring and after you have extracted that method you select the ReadOnly.class use the extract parameter (alt+ctrl+p) refactoring.
You extract ReadOnly.class as a variable via extract variable (alt+ctrl+v) refactroing. Then you select the new Wahtever(... code and use extract method (alt+ctrl+m) and finally you select the extracted variable and use inline variable (alt+ctrl+n).
When using the 1. workflow you have the chance that Intellij Idea will detect the duplicates and suggests a signature change and will extract the other methods as well. That depends on how similar the method calls are.
BTW: That's the knowledge to unleash the power of you IDE. I guess, that I type less then half of my code. The rest is generated by refactoring actions and generators.
Example:
null check via postfix completion:
someObject.null <tab>
will result in:
if (someObject != null) {
<CURSOR>
}
Live templates are another way to store same code patterns in an executable way.
So, given that Java has little to no support to unsigned types, I'm right now writing a small API to handle these (for now, I have UnsignedByte and UnsignedInt). The algorithm is simple: store each of them as their higher representation (byte->short, int->long), extends the Number class and implement some calculation and representation utility methods.
The problem is: it is actually very verbose - and boring - to have to, every time, code things like:
UnsignedByte value = new UnsignedByte(15);
UnsignedByte convert = new UnsignedByte(someIntValue);
I was wondering: is there any way to implement, on Eclipse, something like a "file pre-processor", in a way that it will automatically replace some pre-defined strings with other pre-defined strings before compiling the files?
For example: replace U(x) with new UnsignedByte(x), so it would be possible to use:
UnsignedByte value = U(15);
UnsignedByte convert = U(someIntValue);
Yes, I could create a method called U(...) and use import static, but even then, it would be so much trouble doing it for every class that I would use my unsigned types.
I could write a simple Java program that would replace these expressions in a file, but the problem is: How could I integrate that on Eclipse, in a way that it would call/use it every time a Java file is compiled?
I would recommend using Eclipse Templates for doing this instead. I know its not exactly what you ask for but its very simple and can be achieved out of the box.
When you write sysout in Eclipse and press Ctrl+Space it gives you an option to replace that with System.out.println();
You can find more information in the following link
How to add shortcut keys for java code in eclipse
I can point you at how one project I know of does this, they have a set of Python scripts that generate a whole set of classes (java files) from a template base file. They run the script manually, as opposed to part of the build.
Have a look here for the specific example. In this code they have a class for operating on double, but from this class they want to generate code to operate on float, int, etc all in the same way.
There is, of course, a big debate about whether generated code should be checked in or not to source repository. I leave that issue aside and hope that the above example is good to get you going.
Is there any way of inserting code at runtime to log return values, for instance, using instrumentation?
So far, I managed to insert code when a method exits, but I would like to log something like "method foo returned HashMap { 1 -> 2, 2 -> 3 }"
I'm looking for a general approach that can also deal with, for instance, java.io.* classes. (So in general I'll have no access to the code).
I tried using a custom classloader too, but lot of difficulties arise as I cannot modify java.* classes.
Thanks for the help!
Sergio
Check out BTrace. It's Java, and I believe it'll do what you want.
Have you considered AOP? (Aspect-oriented programming) - if by "I cannot modify java.* classes" you mean you don't have access to the uncompiled code, and cannot add configuration, etc., then that won't probably work for you. In any other case, check that link for examples using Spring-aop:
http://static.springsource.org/spring/docs/2.5.x/reference/aop.html
If not, you could consider solutions based on remote-debugging, or profiling. But they all involve "some" access to the original code, if only to enable / disable JMX access.
Well, since you're looking for everything, the only thing I can think off is using a machine agent. Machine agents hook into the low levels of the JVM itself and can be used to monitor these things.
I have not used DTrace, but it sounds like it would be able to do what you need. Adam Leventhal wrote a nice blog post about it. The link to DTrace in the blog is broken, but I'm sure a quick search and you'll come up with it.
Take a look at Spring AOP, which is quite powerful, and flexible. To start you off on the method foo, you can apply an AfterReturning advice to it as:
#Aspect
public class AfterReturningExample {
#AfterReturning(
pointcut="package.of.your.choice.YourClassName.foo()",
returning="retVal")
public void logTheFoo( Object retVal ) {
// ... logger.trace( "method 'foo' returned " + retVal ); // might need to convert "retVal" toString representation if needed
}
}
The pointcut syntax is really flexible so you can target all the sub packages, components, methods, return values given the expression.
First I want to explain what am I doing and then my problem.
I need to scan a css file and obtain all its internal links(images mainly), but I need to get the line number where the links were found.
Right now I am parsing the files using flute library and it works very well also I am using LineNumberReader in order to obtain the line number where a link was found, but this class throws an incorrect line number.
For example: the link ../../image/bg.gif is in the line number 350 but the method getLineNumber in the class LineNumberReader says 490.
So I will appreciate if some of you can drive me by the correct way and give me a possible explanation why the LineNumberReader class does it.
pd: another solution will be very appreciate.
sorry the possibles typos, English is not my mother tongue.
Another solution --
Have a look at these parser generating tools...
Antlr - http://www.antlr.org/grammar/1240941192304/css21.g
JavaCC - http://sourceforge.net/projects/cssparser/
The JavaCC and Antlr provide a way to get the line number and the column number.
The possible reason for the your problem... the line number one... could be because of the way parser generating tools work... They try to find out the best possible match... for that sometime they have to trackback/rewind the stream.... and due to this your LineNumberReader instance is going out of sync....
The ideal way to get line or column number is to use the methods provided by the tool itself..
Hi #eakbas and #Favonius Thanks for your answer.
I finally got a solution, maybe it is not the best but at least works for me.
As I mentioned before I used the flute library to implement the DocumentHandler class of the package org.w3c.sac package in order to analyze the css file.
So I implemented the 'property' method, this method has 3 parameter, the property name, an LexicalUnit object and a boolean indicating that the property has the important statement or not.
public void property(String property, LexicalUnit lexicalUnit, boolean important)
As I need the line number where a specific property is found, I made a search and I could see that the class that flute uses to implement the LexicalUnit interface holds the line number(it is LexicalUnitImp), so I used reflexion to make a casting from LexicalUnit interface to one LexicalUnitImp object.
Class<?> clazz = ClassUtils.getClass("org.w3c.flute.parser.LexicalUnitImpl");
Object lexicalObject = clazz.cast(lexicalUnit);
Integer line = (Integer)MethodUtils.invokeMethod(lexicalObject, "getLineNumber", null, null);
I did it in that way because the class LexicalUnitImpl is 'protected' and I cannot cast it in a traditional way.
class LexicalUnitImpl implements LexicalUnit
Note: The class ClassUtils and MethodUtils are part of the commons-beanutils apache library.
Alternatively you may use ph-css as a parsing library.
Please see the example "Visit all URLs contained in a CSS" at https://github.com/phax/ph-css#code-examples for an example of how to extract URLs and determine the correct source position.