Better to use reflection or my little hack to access a private method?

Question

I need to access a private method from another class. I have two ways of accessing it. The first is the obvious reflection. The second is sort of a hack. The private method I need to call is being called from a protected inner class's accessPrivateMethod method. This method will literally only call the private method I need. So, is it better to access it using reflection or is it better to sort of "hack" it by extending the protected inner class that calls it. See code:

method = object.getClass().getDeclaredMethod("privateMethod");
method.setAccessible(true);
Object r = method.invoke(object);

Or: (ProtectedInnerClass is a protected inner class in the class whose private method I want to access.)

class Hack extends ProtectedInnerClass {
    public void accessPrivateMethod() {
        // callPrivateMethod literally only calls the private method
        // I need to call.
        super.callPrivateMethod();
    }
}
...
Hack.accessPrivateMethod();

Some additional thoughts:

1) I've seen many people on here say to use reflection only as a last resort.

2) Reflection could cause Security issues? (SecurityManager can deny the setAccessible sometimes?) This needs to work all the time on any machine/setup.

If my hack isn't clear please say so and I will try to elaborate more. Thanks!

PS: the private method I need to access is in the JUNG libraries. Calling it fixes a bug. AKA I'm trying to find a workaround without having to edit any of the JUNG jars.

Answer 1

1) I've seen many people on here say to use reflection only as a last resort.

Assuming your hack actually works, it is better to use that, rather than using reflection. This is because using reflection is way more expensive.

Here's an extract on Java's API concerning reflection :

• Because reflection involves types that are dynamically resolved, certain Java virtual machine optimizations can not be performed. Consequently, reflective operations have slower performance than their non-reflective counterparts, and should be avoided in sections of code which are called frequently in performance-sensitive applications.

2) Reflection could cause Security issues? (SecurityManager can deny the setAccessible sometimes?) This needs to work all the time on any machine/setup.

Likewise:

• Reflection requires a runtime permission which may not be present when running under a security manager. This is in an important consideration for code which has to run in a restricted security context, such as in an Applet.

So, not only the setAccessible method may be denied, but the reflection usage overall.

Another consideration is that in order to call your Hack class method without instantiation, you need to set the inner method as static.

class Hack extends ProtectedInnerClass {
   public static void accessPrivateMethod() {
       super.callPrivateMethod();
   }
}
Hack.accessPrivateMethod();

Answer 2

The fact that this question rises is probably caused by bad design or the fact that Java doesn't allow "sub-package" visibility. However, if performance is a concern, go for the "little" hack. Otherwise, choose the esthetic solution using reflections. But in first place, try to find out if your design is good.