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?