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
anyone would want to glean anyway.

Scott

On Wed, Sep 24, 2008 at 3:15 PM, Laurie Harper <[EMAIL PROTECTED]> wrote:

> 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.jenkov.com%2Fjava-reflection%2Fgenerics.html
>>
>> On 9/23/08, Laurie Harper <[EMAIL PROTECTED]> wrote:
>>
>>> 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()
>>>>> <which
>>>>> it
>>>>> 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 type is specifically spelled out and the framework
>>>>> decides a type diametrically opposed, this is a problem.:teeth:
>>>>>
>>>>>
>>>>>
>>>>> Gabriel Belingueres-2 wrote:
>>>>>
>>>>>> 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:
>>>>>>
>>>>>> <s:property value="aMap[abc].id"/>
>>>>>>
>>>>>> 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 are all good points, but when my collection was expressly
>>>>>>> declared
>>>>>>> to
>>>>>>> be a Map<String, Employee> 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
>>>>>>>
>>>>>>> On Mon, Sep 22, 2008 at 7:53 PM, Gabriel Belingueres
>>>>>>> <[EMAIL PROTECTED]>wrote:
>>>>>>>
>>>>>>>  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  <[EMAIL PROTECTED]>:
>>>>>>>>
>>>>>>>>> I expected the conversion facility or iterator key to be smart
>>>>>>>>> enough
>>>>>>>>>
>>>>>>>> to
>>>>>>>>
>>>>>>>>> recognize my Map<String, Employee> 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 Belingueres
>>>>>>>>> <[EMAIL PROTECTED]>wrote:
>>>>>>>>>
>>>>>>>>>  Interesting. Seems it is a feature, as documented in [1].
>>>>>>>>>>
>>>>>>>>>> Tested it myself:
>>>>>>>>>> <s:property value="1234h.class.name" />
>>>>>>>>>> <s:property value="1234b.class.name" />
>>>>>>>>>> <s:property value="1234F.class.name" />
>>>>>>>>>> <s:property value="1234L.class.name" />
>>>>>>>>>> <s:property value="1234d.class.name" />
>>>>>>>>>> <s:property value="(1234).class.name" />
>>>>>>>>>>
>>>>>>>>>> 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 returns
>>>>>>>>>> nothing, since the map key is a string and you need to quote it
>>>>>>>>>> accordingly.
>>>>>>>>>>
>>>>>>>>>> [1]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> http://www.ognl.org/2.6.9/Documentation/html/LanguageGuide/basicExpressions.html#constants
>>>>>>>>
>>>>>>>>> 2008/9/22 stanlick <[EMAIL PROTECTED]>:
>>>>>>>>>>
>>>>>>>>>>> I encountered a very strange situation today.  I had the
>>>>>>>>>>> following
>>>>>>>>>>>
>>>>>>>>>> in
>>>>>>>> a
>>>>>>>>
>>>>>>>>> web
>>>>>>>>>>
>>>>>>>>>>> page:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> <s:iterator value="employees">
>>>>>>>>>>>   <s:textfield name="employees[%{key}].id .../>
>>>>>>>>>>>
>>>>>>>>>>> where the get method in my action was:
>>>>>>>>>>>
>>>>>>>>>>> public Map<String,Employee> getEmployees()
>>>>>>>>>>>
>>>>>>>>>>> The employee id 7932F was being interpreted as 7932!  The
>>>>>>>>>>> trailing
>>>>>>>>>>>
>>>>>>>>>> "F"
>>>>>>>>
>>>>>>>>> was
>>>>>>>>>>
>>>>>>>>>>> apparently being considered a literal for FLOAT and was being
>>>>>>>>>>>
>>>>>>>>>> trimmed
>>>>>>>> off
>>>>>>>>
>>>>>>>>> the String.
>>>>>>>>>>>
>>>>>>>>>>> When I wrapped the variable in quotes is worked
>>>>>>>>>>>
>>>>>>>>>>>  <s:textfield name="employees[  '%{key'  }].id .../>
>>>>>>>>>>>
>>>>>>>>>>> Does this appear to be a bug?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> View this message in context:
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> http://www.nabble.com/Custom-tag-and-map-backed-action-tp19614086p19614086.html
>>>>>>>>
>>>>>>>>> Sent from the Struts - User mailing list archive at Nabble.com.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>>>>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>>>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>>
>>>>>>
>>>>>>
>>>>>>  --
>>>>> View this message in context:
>>>>>
>>>>> http://www.nabble.com/Custom-tag-and-map-backed-action-tp19614086p19629362.html
>>>>> Sent from the Struts - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Reply via email to