Generics and reflection

I have this really ugly thing regarding generics and reflection (and
probably one of those type-erasure weaknesses):

Suppose I have this:
public interface Delegate<Ret, T> {
public Ret doStuffWith(T t);
}

I want to make a special kind of delegate:
public class FieldDelegate<Ret, T> implements Delegate<Ret, T> {
private String fieldName;
//...
}

The idea is that in doStuffWith() in the FieldDelegate, I'd grab and
return a (public) field through reflection. Having said that, though,
I think I may have hit a few problems:

1. I don't know what the Ret class is - ever. (How I hate type-
erasure for this...)
2. With this structure, the only time I can get the T class is in
doStuffWith() (ie. t.getClass()), which means I have to check the
validity of the field name every time I call doStuffWith(). Fine, so
I change it to

private Field field;
public FieldDelegate(String fieldName, Class<Ret> retClass, Class<T>
tClass); // Might as well fix the first issue

so that the check is in the constructor. With this, I can check
whether class T has a field with the name fieldName and whether the
type of the field is assignable to the returning class (easy enough),
but now I have another two issues:

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()).
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).

I guess this is one of those times where you wished you had some
syntactic-sugar for T.class, standing for some hidden Class<T>
parameter that's passed in. Anyways, is there any way of getting
around these two issues?

.

Relevant Pages

  • Re: Calling an internal constructor
    ... there is nothing you can do to call this constructor from ... your constructor in code (even through reflection) so that your class can ... > internal constructor (The CurrencyManager class). ... > derived from BindingManagerBase, and though the documentation has a "Note ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Reflection, how to understand
    ... I'm trying understand jdk 5 reflection. ... Then it proceeds to get a constructor for said class, ... Then it proceeds to instantiate the object using said constructor, ... I use that code snippet for persistence of simple objects ...
    (comp.lang.java.programmer)
  • Re: Reflection
    ... Alternatively you can use Reflection, ... > constructor, how do i go about instantiating it. ... > but for some odd reason i never am able to instantiate my objects ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: default values
    ... reflection and call through reflection. ... >> or not the type derives from ValueType in some way. ... If it does not derive from ValueType, then it is a reference>> type, and the default value is null. ... >>> I'd have hoped that the boxed equivalent of the value type would have a>>> constructor, ...
    (microsoft.public.dotnet.languages.csharp)