Re: Generics and reflection
On Apr 4, 7:20 pm, Tom Hawtin <use...@tackline.plus.com> wrote:
kelvSYC wrote:
I have this really ugly thing regarding generics and reflection (and
probably one of those type-erasure weaknesses):
Are you sure you want to be using reflection at all? Reflection should
be kept for extra special occasions. It's generally a bad idea.
1. I don't know the access level of the field. Calling doStuffWith()
may still throw some kind of access violation exception (from
field.get(t)). I don't know how to catch that in the constructor (the
check's done in the constructor so that I don't have to check in
doStuffWith()).
Check the field type in the constructor. You can satisfy Java's checked
exception mechanism (which can only follow a limited set of rules) by
rethrowing exceptions from the method wrapped in an unchecked exception
(an Error).
2. I now have to pass in the class objects in the constructor (which
ideally you don't want to do), which seems a bit redundant (but given
type erasure, I guess necessary).
Well, you are doing some messy stuff. Using a static creation method
would help a little. But it's what, for instance,
AtomicReferenceFieldUpdater has to do.
Just to reiterate, reflection is unlikely to be a good answer.
Tom Hawtin
To iterate again, reflection is usually (not always) a bad design
decision... I would say the only good reason to use it is if you are
creating a "framework" (JUnit, Spring, Hibernate, etc... all use
reflection in a good way), or an IDE/developers tool.
Anyway, the alternative to what your doing is to create an interface
Delegate (like you do) and then write concrete version of it for the
fields you need to delegate to. That way, you know exactly whats
going on at compile time, no run-time trickery involved.