Reputation: 2155
I have spend the last 1 or 2 hours diving into Java reflection. I think i'm starting to have a proper understanding.
I could not however find a few answers I was looking for.
What I came to understand is that reflection suffers a big(biggest?) performance hit from class lookups.
I have 2 questions.
How can you call a method from within the current context(is it even possible?)? And will the performance hit from class lookups be canceled out when calling within the current context?
for example:
class User {
private String name;
public getName(){ return name; }
public setName(String name){ this.name = name; }
public void doSomething() {
//some random stuff
//I would like this method to invoke randomMethod();
//Since it is within the same context(this)
//Will this reduce the performance cost?
//Please assume from my goals that I will ALWAYS know the name of the method i want to call.
//So I wont need to loop through all available methods.
}
public void randomMethod() {
}
}
Im trying to achieve some kind of dispatcher. For example for web development in Java.
Im not interested in frameworks etc.
So if a user enters an url http://www.hiurl.com/home/index
Where home is the controller and index the action(the method name to be called by reflection).
If you have good arguments why to absolutely avoid this apart from the many chances of failing, please let me know aswell.
I hope my question is clear. Thanks for taking the time to read and I look forward to read your replies.
Upvotes: 0
Views: 3188
Reputation: 200296
You should absolutely not worry about performance if all you are doing is dispatching to the controller method. The whole issue of the slowness of reflection is when you are comparing 1ns needed to directly call a method with maybe 100ns needed for lookup + invocation. BTW I would prefer reflection to the Strategy pattern, but those two are indeed quite close, so it's your call.
Upvotes: 1
Reputation: 3842
No, unfortunately one cannot optimize subsequent method calls via reflection even if all of them are executed on the same instance. The reason for this basically is the signature of reflection methods for invocation:
// in java.lang.reflect.Method
Object invoke(Object instance, Object... args);
// in java.lang.reflect.Field
Object get(Object instance)
The only thing one can do to optimize calls using reflection is to store references to Method
, Field
, Constructor
etc. in order to avoid costly lookups each invocation e.g:
public class User {
public void methodToBeCalledUsingReflection() {
// some logic
}
public void invocationWithPerformanceHit() {
// lookup of Method instance - costly operation!
Method method = User.class.getMethod("methodToBeCalledUsingReflection");
// actual invocation of method
method.invoke(this);
}
public void invocationWithoutPerformanceHit() {
// only actual invocation of method
method.invoke(this);
}
// moving Method instance to static field which is initialized (looked up) only once
public static final Method method = getMethodReference("methodToBeCalledUsingReflection");
private static Method getMethodReference(String methodName) {
try {
return User.class.getMethod(methodName);
} catch(Exception ex) {
throw new RuntimeException(ex);
}
}
}
Besides that, I would recommend using Reflection only if it's highly justified since it hampers performance, is less typesafe and has some other drawbacks. If one can go without Reflection, one should not use it.
Upvotes: 3
Reputation: 5601
There is no difference from what kind of context you are going to invoke you method, in all cases you are doing it in the same manner. You need to pass 'this' object to invoke method.
Look at: http://www.java2s.com/Code/Java/Reflection/CallamethoddynamicallyReflection.htm
Upvotes: 0
Reputation: 343
If i understand you correctly you want to execute different parts of code for a given string.
i think you should avoid reflection if there is a more "regular" way doing this, simply because of better code readability.
Think of using something like the strategy pattern. Should work well in your case.
Upvotes: 2