Like you, I was under the impression that generics were erased and you were
out of luck at runtime! After the type conversion burn at the top of this
thread, I started to dig in and found this article. I have experimented
with it and it works great. As it turns out, this is probably about all
an
I stand corrected -- and thanks for the link; I've never seen this
documented before. Very interesting...
L.
[EMAIL PROTECTED] wrote:
http://www.google.com/gwt/n?eosr=on&q=Reflection+generics+Java+&source=m&hl=en&ei=ZWfZSODxI5nYqAKR1t53&sa=X&oi=blended&ct=res&cd=4&rd=1&u=http%3A%2F%2Ftutorials
http://www.google.com/gwt/n?eosr=on&q=Reflection+generics+Java+&source=m&hl=en&ei=ZWfZSODxI5nYqAKR1t53&sa=X&oi=blended&ct=res&cd=4&rd=1&u=http%3A%2F%2Ftutorials.jenkov.com%2Fjava-reflection%2Fgenerics.html
On 9/23/08, Laurie Harper <[EMAIL PROTECTED]> wrote:
> Sounds reasonable until you remember
Sounds reasonable until you remember two words: type erasure. There is
no way to 'glean the generic type' of a collection at runtime.
L.
Gabriel Belingueres wrote:
I agree too.
2008/9/23 stanlick <[EMAIL PROTECTED]>:
I agree totally! If the TypeDeterminer had called getEmployees() *and* ha
I agree too.
2008/9/23 stanlick <[EMAIL PROTECTED]>:
>
> I agree totally! If the TypeDeterminer had called getEmployees() clearly did for iterator> *and* had bothered to glean the generic type of
> the key, it would have recognized the action expected the key to of type
> String. If the data ty
I agree totally! If the TypeDeterminer had called getEmployees() *and* had bothered to glean the generic type of
the key, it would have recognized the action expected the key to of type
String. If the data type is specifically spelled out and the framework
decides a type diametrically opposed,
AFAIK, OGNL does not have any support for generics, but even if it
would support it, I would prefer that it wont be too smart, for
example in:
I prefer that abc be treated as an action property and call method
getAbc() than coerce it to the string 'abc'.
2008/9/23 <[EMAIL PROTECTED]>:
> Those
Those are all good points, but when my collection was expressly declared to
be a Map I would sort of expect the key to be a String!
When the framework "guesses" for a different type (feature?) and your
application fails; all the discussion about valid number systems is sort of
meaningless.
Scott
I don't know but I hope not, since I don't want my expressions to
reduce to different data types depending if there is a number or not
in them!
Even if abc would reduce to the string 'abc', the expression 0xabc
reduce to an Integer (have tested it), since it is an hexadecimal
number.
2008/9/22 <[
I expected the conversion facility or iterator key to be smart enough to
recognize my Map and setup the internal key variable
accordingly. Do you suppose it would have worked if my Map had contained
'abc':emp1, 'def':emp2, 'ghi':emp3?
Peace,
Scott
On Mon, Sep 22, 2008 at 3:47 PM, Gabriel Belingu
Interesting. Seems it is a feature, as documented in [1].
Tested it myself:
The last one (Integer) didn't work without the ( ), which I don't know
if this is a necessity or a bug.
What about Short and Byte data type? it doesn't say...
However, I think is NOT a bug that employees[1234F].id
11 matches
Mail list logo
