I am currious how reflection will be updated to handle generics. If I have a Collection<Integer> and store the instance in variable x, what will be the result of x.getClass(). How will you do a getMethod() call for generic types if a method is foo.(final Set<T> input); ?? Finally, what will be the impact on the instanceof operator and its dynamic cousins ?
I am currious how reflection will be updated to handle
generics.
One of the earlier prototype releases had JavaDoc for reflection related type. It is not contained in the latest prototype although the reflection types were modified (e.g. Class is not Class<T>). Is there an update of the JavaDoc available somewhere?
So, I do not know much, but I can try and guess ...
If I have a Collection<Integer> and store
the instance in variable x, what will be the result of
x.getClass().
Collection.class, which is of type Class<Collection>
Interestingly, there is no isParameterized() method. If you want to know whether the class is a parameterized type you'll probably invoke the getTypeParameters() method. If it return an empty array then the type is a non-generic type.
How will you do a getMethod() call for
generic types if a method is foo.(final Set<T> input);
??
As usual, I would think. For the argument type Set<T> you would pass in Set.class.
I am wondering whether bridge methods will be visible. If I call getMethods(), will I see the bridge methods? Will they be contained in the array of methods that is returned?
Finally, what will be the impact on the instanceof
operator and its dynamic cousins ?
I would think that instanceof does the equivalent of the corresponding cast. There is a compile-time check: if the compiler finds that the cast can never succeed the instanceof expression will be rejected at compile-time. Otherwise the usual runtime check is performed, based on erasures, of course. The methods isInstance() and isAssignableFrom() will hopefully be compatible to the runtime part of instanceof.
It seems to be an open issue whether parameterized types and type variables can appear in instanceof expressions. The spec allows both; the compiler accepts parameterized types, but not type variables; it has been mentioned on this forum that parameterized types must not appear in instanceof expressions either. By and large: not settled yet.
One of the earlier prototype releases had JavaDoc for
reflection related type. It is not contained in the
latest prototype although the reflection types were
modified (e.g. Class is not Class<T>). Is there an
update of the JavaDoc available somewhere?
http://cscott.net/Projects/GJ
has javadoc for all the code distributed with the current prototype 2.2 compiler. This does not include an updated reflection API, because code to support that is not included in the current prototypes. I don't know exactly what Neil's plans are for this.
You can get a basic idea from the 1.2 prototype API:
http://cscott.net/Projects/GJ/Doc/v12/jsr-14-public-draft/reflection-javadoc/
But this has several fundamental problems with representing nested parameterized types. The sinjdoc API was created after some discussions with Sun, and reflects the current thinking on representing parameterized types; see net.cscott.sinjdoc.ParameterizedType at:
http://cscott.net/Projects/GJ/sinjdoc-latest/doc/index.html
How will you do a getMethod() call for
generic types if a method is foo.(final Set<T>
input);
??
As usual, I would think. For the argument type Set<T>
you would pass in Set.class.
Yes, you use the erased types. The JSR-14 spec ensures that the signatures after erasure will always be distinct.
I am wondering whether bridge methods will be visible.
If I call getMethods(), will I see the bridge
methods? Will they be contained in the array of
methods that is returned?
Don't know. The new JVM spec provides for special marking of 'synthetic' members; possible all synthetic members (bridge methods, some methods of inner classes, etc) will be hidden. You're right, that bridge methods pose a special problem in that the parameter types are identical, but the return type differs. The current java.lang.Class API only allows you to specify the desired parameter types, not the return type.
I am wondering whether bridge methods will be visible.
If I call getMethods(), will I see the bridge
methods? Will they be contained in the array of
methods that is returned?
Yes, and they will have the new ACC_BRIDGE modifier.
If you read the documentation for getMethod(), it says that any of the methods may be returned when multiple methods have the same type signature (excluding return type). I filed a bug report/rfe about this many moons ago and was told that the behavior would not be changed.
Needless to say, I personally found that answer, dissatisfying.
If you read the documentation for getMethod(), it says
that any of the methods may be returned when
multiple methods have the same type signature
(excluding return type). I filed a bug report/rfe
about this many moons ago and was told that the
behavior would not be changed.
You can always get the complete list of methods and select the one you want. In 1.5 I believe getMethod() will get the one the user wrote - that is, the non-bridge method.
You can always get the complete list of methods and
select the one you want.
What is the purpose of getMethod() if not to aid you
in avoiding looping through all of the methods defined
in the class? Oy vey!
It does just that, when the API can unambiguously specify the method youu want. When it can't, you will need to use some other mechanism. For programs generated from Java source, you should have no need for looping through all methods.
[sigh] (Why do I even bother? You have to be one of the most frustrating people with which I've ever tried to communicate).
When it can't, you will need to use some other mechanism.
It could if the API weren't broken and just took a return type. And how much effort could that possibly take to affect? Probably less time than it took me to put this post together. There's just no excuse at all.
For programs generated from Java source, you should have no need for looping through all methods.
Not true at all. I can easily see cases where I would read some declarative data structure that would specify the desired return type and a false hit would make me have to walk all of the methods instead of calling getMethod.
You can always get the complete list of methods and
select the one you want. In 1.5 I believe getMethod()
will get the one the user wrote - that is, the
non-bridge method.
This is all I was looking for: a pledge to "try hard" to make getMethod() Do The Right Thing in 1.5. This corner case might otherwise be overlooked and Bad Things Could Happen.
For programs generated from Java source, you should
have no need for looping through all methods.
Not true at all. I can easily see cases where I would
read some declarative data structure that would
specify the desired return type and a false hit would
make me have to walk all of the methods instead of
calling getMethod.
If you're looking for those synthetic bridge methods, that is true. If you're looking for the ones that appeared in the source, the name and parameter types uniquiely identify it.
I cant help but agree. The JDK team is sidestepping the whole area of reflection almost as if they have plans to deprecate the entire concept. Look at my post "Erasure: Is it really needed?" The result of their current lack of oversight will be to totally bork the reflection API back into the stone age. The most powerful tool in the JDK is about to be slammed.
Sigh .. without a firm comitment on this I suppose im going to have to warn about this in my book. I was hopeing I could answer the questions of my readers.
And the replies from gafter make no sense. If we knew what method woul be called at compile time, we wouldnt need reflection. Therefore the method can only be distinguished at run time. But wait!!! With reflection it cant be distinguished at all. The answer to your question is that there is NO WAY for you to get the proper method. Full stop. Entire reflection mechanism is dead.
Perhaps you should calm down and explain. Maybe I'm just not following closely enough, but so far I don't understand what it is you're worried about.
You asked for code examples in the other thread, so I'll turn that around and ask you in turn. Please show me:
(i) some class that uses generics
(ii) some reflective code that finds a method in that class at runtime and calls it, as far as possible with the current prototype or specification
(iii) a hypothetical example of how you'd like it to work. ie, show me which (presumably more specific) method you'd like to find, and how calling it result in clearer or safer code.
Right now this discussion is just too abstract for me. In order for anyone to agree with you that there's a problem, we need to understand what it is.
Im quite calm. Im very assertive about this because I think its important. If it isnt resolved, I intend to start a campaign in the JCP to get JDK 1.5 REJECTED by the voters.
Maybe I'm
just not following closely enough, but so far I don't
understand what it is you're worried about.
Please read this topic in full:
http://forum.java.sun.com/thread.jsp?forum=316&thread=443274&tstart=0&trange=50
You asked for code examples in the other thread, so
I'll turn that around and ask you in turn. Please show
me:
If you read the other thread completely it answers all three of your questions.
(i) some class that uses generics
In the other thread.
(ii) some reflective code that finds a method in that
class at runtime and calls it, as far as possible with
the current prototype or specification
Cant be done as the other thread shows. Erasure blocks it.
(iii) a hypothetical example of how you'd like it to
work. ie, show me which (presumably more specific)
method you'd like to find, and how calling it result
in clearer or safer code.
The other thread explains this.
Right now this discussion is just too abstract for me.
In order for anyone to agree with you that there's a
problem, we need to understand what it is.
I defined it in the other thread. Perhaps reading it more closely might help you understand what Im talking about. I do not intend to repeat myself yet again.
This topic has
17
replies
on
2
pages.
1
|
2
|
Next »
Email this Topic
Edit this Topic
