Why is it a bad idea to create a generic setter and getter with reflection?

Question

A while back I wrote this answer to a question on how to avoid having a getter and setter for every mutable variable. At the time, I had only a hard-to-verbalize gut feeling that this is a Bad Idea, but OP was explicitly asking how to do it. I searched here on why this might be a problem, and found this question, whose answers seem to take it as a given that using reflection unless absolutely necessary is bad practice.

So, can someone verbalize why it is a given that reflection should be avoided, specifically in the case of the generic getter and setter?

Answer 1

Downsides of reflection in general

Reflection is harder to understand than straight-line code.

In my experience, reflection is an "expert-level" feature in Java. I would argue that most programmers never use reflection actively (i.e. consuming libraries that use reflection doesn't count). That makes code using it harder to understand for these programmers.

Reflection code is inaccessible to static analysis

Suppose I have a getter getFoo in my class and I want to rename it to getBar. If I use no reflection, I can just search the code base for getFoo and will find every place that uses the getter so I can update it, and even if I miss one, the compiler will complain.

But if the place that uses the getter is something like callGetter("Foo") and callGetter does getClass().getMethod("get"+name).invoke(this), then the above method won't find it, and the compiler won't complain. Only when the code is actually executed will you get a NoSuchMethodException. And imagine the pain you're in if that exception (which is tracked) is swallowed by callGetter because "it's only used with hard-coded strings, it can't actually happen". (Nobody would do that, someone might argue? Except that the OP did exactly that in his SO answer. If the field is renamed, users of the generic setter would never notice, except for the extremely obscure bug of the setter silently doing nothing. Users of the getter might, if they're lucky, notice the console output of the ignored exception.)

Reflection code is not type-checked by the compiler

This is basically a big sub-point of the above. Reflection code is all about Object. Types are checked at runtime. Errors are discovered by unit tests, but only if you have coverage. ("It's just a getter, I don't need to test it.") Basically, you lose the advantage using Java over Python gained you in the first place.

Reflection code is unavailable for optimization

Maybe not in theory, but in practice, you won't find a JVM that inlines or creates an inline cache for Method.invoke. Normal method calls are available for such optimizations. That makes them a lot faster.

Reflection code is just slow in general

The dynamic method lookup and type checking necessary for reflection code is slower than normal method calls. If you turn that cheap one-line getter into a reflection beast, you might (I have not measured this) be looking at several orders of magnitude of slowdown.

Downside of generic getter/setter specifically

That's just a bad idea, because your class now has no encapsulation anymore. Every field it has is accessible. You might as well make them all public.

Answer 2

Because pass-through getter/setters are an abomination that provide no value. They don't provide any encapsulation since users can get at the actual values via the properties. They are YAGNI because you're rarely if ever going to change the implementation of your field storage.

And because this is way less performant. In C# at least, a getter/setter will inline straight to a single CIL instruction. In your answer, you're replacing that with 3 function calls, which in turn need to load metadata to reflect over. I've generally used 10x as the rule of thumb for reflection costs, but when I searched for data, one of the first answers included this answer which ballparked it closer to 1000x.

(And it makes your code harder to debug, and it harms usability because there's more ways to misuse it, and it harms maintainability because you're now using magic strings rather than proper identifiers...)

Answer 3

In addition to the arguments already presented.

It doesn't provide the expected interface.

Users expect to call foo.getBar() and foo.setBar(value), not foo.get("bar") and foo.set("bar",value)

To provide the interface that users expect you need to write a seperate getter/setter for each property. Once you have done that there is no point in using reflection.

Answer 4

Of course is not a bad idea, it is just than in a normal java world is a bad idea(when you only wants a getter or setter). For example some frameworks(spring mvc) or librares already use it(jstl) in that way, some json o xml parsers are using it, if you want to use a DSL you are going to use it. Then it depends on your use case scenario.

Nothing is right or wrong as a fact.