My need is pretty simple: I want to change a method call objClass1.method1() by a call objClass2.method2() in my whole Eclipse project. Unfortunately, I can't find a plugin able to do this. Can you help?
Edit:
To be more accurate, objClass1 is part of a third party library, so I need to change the method calls. I can't start at the method definition. When I right-click on a method1 call, I have no "rename" option in my "Refactor" menu.
I don't want to change or rename my methods. I want to exchange one call by another in my whole project.
An example of what needs to be done:
Before refactoring:
Injector injector=Guice.createInjector(new IContactModule());
After refactoring:
Injector injector=IContactInjectorSingleton.getInjector();
And this needs to be done a several points in my project.
What you ask for is no refactoring. A refactoring is defined as "a change that alters the code while not changing the behavior of the code". In this sense renaming a class or renaming a method is a refactoring (you change the code but the program does the same as before). But what you suggest does NOT preserve the behavior of the code so there will never be a "refactoring" for this.
Of course one might be able to write a plugin that is able to perform the text changes you want in a more or less safe way. But this will only work in very specific circumstances (what if your new method needs an argument the old one dons't need? What if there are more than one method with the same name but different parameters? ...). So I don't believe such a plugin exists, nor it makes much sense to develop such a plugin.
Just right click on the class/method name and choose Refactor > Rename.
EDIT:
To be more accurate, objClass1 is part of a third party library, so I need to change the method calls. I can't start at the method definition. When I right-click on a method1 call, I have no "rename" option in my "Refactor" menu.
Hence I would suggest you to simply make a replacement:
Search menu > File, type the old name, choose the context of the search ("Enclosing project"), click on Replace and type the new name.
EDIT2:
From the example you added to the question I think that a manual replacement, using the tool I just suggested, it's the best way. It's a complex issue, as #Arne pointed out, so it's better to make it in a controlled way. Moreover I doubt it is such a frequent operation to require a plugin to be built.
You could use the eclipse refactoring by selecting the methods name. Right click for context menu or Alt-Shift-R, in the Rename-Dialog a preview dialog is available which shows all suggested changes in one place.
First, move the body of objClass1.method1() into objClass2.method2(), and have method1 simply call method2. It may not be quite as "simple" as that, if for instance method1 uses fields of Class1 for instance, in which case you should probably include this as a parameter to the new method and perhaps use getters for the fields. If you can make the method static before doing this, it will be easier to avoid those kinds of problems. Anyway, make that transformation, so method1 is just calling method2. Now use the Inline Method refactoring to make method1 go away. You're done.
Related
My company's coding standards dictate that when invoking local methods, we have to prefix the call with this.
Is there an inspection I can enable in Intellij so that places where localMethod() are used instead of this.localMethod() are highlighted?
In addition to this, I frequently use the extract method function that Intellij offers, however the method call that gets left behind is localMethod() rather than this.localMethod(), is there a way I can alter the code that is inserted when using this extraction to include this automatically?
Yes, there is such an inspection. It's called "Instance method call not qualified with 'this".
I don't think there's an option for "Extract method" to always add 'this' qualifiers.
Interesting question here. So I have a .jar I received and it is obfuscated, meaning when I decompile the .class files it doesnt show up 100% perfect so I cannot recompile it. However the only method I need to change has been converted perfectly (but the class does not)). Is there a way to somehow change the .java code and inject replace the method within the class file without totally recompiling?
If this fails im going to bytecode.
Thanks!
EDIT: As a follow up question / or a hack around replacing the WHOLE method. I'm really just trying to change a variable that the method generates locally. If there are any better ways to do that.
Depending on what you really want to do, I do not recommand to decompile / modify / recompile the code (be it for legal, maintainance, understandability, testability reasons.)
Bytecode manipulation may not be the best solution either, but if you want to follow this way have a look at the ASM project, it's a widespread bytecode manipulation framework used by many known projects.
If I were you I would first give a try to aspects (AspectJ.) The power of aspects is that you don't touch existing code, but tell the VM what to do when / before / after / in place of calling a specific method. It allows you to point out the exact context and change, enhance the behavior of the code, by writing your own code in a decoupled fashion.
Hope it helps.
Sorry, this is not an answer, but it is too long for a comment...
I am reflecting this code, not using it as a library. So I dont really need to "use" this code (aka I'm just reflecting and calling functions at runtime).
I'd call the "reflecting and calling functions at runtime" as using the code.
There might be the reasons why to do that, but I'd prefer to simply call the function as a library function if possible (which should be possible if you can do the same using reflection).
...and manually overload it.
There is nothing simpler that extending the class and override a "wrong" method. As of my understanding even if you want to "inject" the method, you have to have the code somewhere. How you will test such code? It'd be a lot easier to just extend the class... Can you specify in bigger detail what you want to achieve with a reasoning why you cannot use what I wrote above?
If you want to change just one method you can actually extend the class and then #Override the method!
Don't know if this is the perfect way to do it,but it works!
I have a class which behavior I would like to change. I need to replace private method with another realization. Common reflection techniques allow to modify private variable or to invoke private methods. But I find little information about replacing entire methods.
I presume that there are advanced techniques to do so. May be its impossible with standard java reflection but there are probably other tools to recompile byte code in runtime.
Modify & replace:
One option is to mask the class with a modified copy (modify code, recompile code, add modified classes to the classpath before patched classes), similar to the approach used here to inspect how a normally unavailable method works.
If you do not have sources to modify, you can "reverse" almost any .class file into more-or-less readable source code using decompilers. Notice that, depending on licensing, you may not have permission to do so and/or to redistribute your changes.
Patch via agent:
You can also patch the methods using the -javaagent:<jarpath>[=<options>] commant-line option. The "agent" is a jar that gets to modify loaded classes and alter their behaviour. More information here.
Mock:
If you have control over where the methods are called, you can replace the target instance with a stubbed version. Libraries such as Mockito make this very, very easy:
LinkedList mockedList = mock(LinkedList.class);
// stubbing appears before the actual execution
when(mockedList.get(0)).thenReturn("first");
Even though Mockito does not support mocking private methods natively (mostly because it is considered bad manners to look at other classes' privates), using PowerMock allows you to do so (thanks, #talex).
You can't replace method in runtime (at least without hack into JVM). But you can replace whole class. There are several way to do it. For example you can use thing called "aspect".
But from my experience I can say that if you need to do this you have wrong turn somewhere in beginning of you way.
Maybe you better make one step back and look at whole picture
Instead of going for advanced techniques, there is a simple trick to achieve this.
If you class is part of an open-source jar, get source code of this class file from grepcode.com. Change the method that you want to change and compile it. And update your jar file/classpath with this updated class file.
I was wondering if there is a quick way of identifying or displaying which classes are trying to call a method.
Its easy to do this if there are only few classes present. But what if there are hundreds of classes trying to call a method in other classes. It would be extremly tedious if I do this manually. Is there a plugin or some built-in functions that would do this in eclipse?
The reason am asking is I wanted to map out different classes that are calling methods from other classes for easy debugging.
Right click your function, select references, and then choose what you want (generally project). That will show all the references to this function in the project. This also works for classes, variables, and probably other stuff too.
You can try an eclipse's Call Hierarchy feature. It shows you all the methods which directly call the method you are interested in. You can expand each caller and see what methods call it and so on.
You can do it buy right clicking on the method and selecting an "Open Call Hierarchy" menu item or pressing Ctrl+Alt+H Hotkey.
This seems like it should be fairly straight-forward, but I can't see anything obvious. What I basically want to do it to point at a method and refactor->extract class. This would take the method in question to a new class with that method as top level public API. The refactoring would also drag any required methods and variables along with it to the new class, deleting them from the old class if nothing else in the old class is using it.
This is a repetitive task I often encounter when refactoring legacy code. Anyway, I'm currently using Eclipse 3.0.2, but would still be interested in the answer if its available in a more recent version of eclipse. Thanks!
I don't think this kind of refactoring exists yet.
Bug 225716 has been log for that kind of feature (since early 2008).
Bug 312347 would also be a good implementation of such a refactoring.
"Create a new class and move the relevant fields and methods from the old class into the new class."
I mention a workaround in this SO answer.
In Eclipse 3.7.1 there is an option to move methods and fields out of a class. To do so:
Make sure the destination class exists (empty class is fine, just as long as it exists in the project).
In the source class, select the methods that you want to remove (the outline view works great for this), right click on the selection, and choose Move
Select the destination class in the drop down/Browse
Your members are now extracted. Fix any visibility issues (Source > Generate Getters and Setters is very useful for this) and you are all set.
This seems like it should be fairly
straight-forward...
Actually, Extract Class is one of the more difficult refactorings. Even in your simple example of moving a single method and its dependencies, there are possible complications:
If the moved method might be used in code you don't know about, you need to have a proxy method in the original class that will delegate to (call) the moved method. (If your application is self-contained or if you know all the clients of the moved method, then the refactoring code could update the calling code.)
If the moved method is part of an interface or if the moved method is inherited, then you will also need to have a "proxy method".
Your method may call a private method/field that some other method calls. You need to choose a class for the called member (maybe in the class that uses it the most). You will need to change access from "private" to something more general.
Depending on how much the original class and the extracted class need to know about each other, one or both may need to have fields initialized that point to the other.
Etc.
This is why I encourage everybody to vote for bug 312347 to get fixed.
Have you tried the Move feature of the Refactor group ? You can create a helper class and move there anything you want.