commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simone.trip...@gmail.com>
Subject Re: [POOL] can the CheckedObjectPool be removed when introducing Java5 generics?
Date Tue, 12 Oct 2010 11:31:49 GMT
Hi Seb,
thanks for your feedbacks, I'm more for changing the method signature
rather than loose the power of generics, but that's just my opinion.
Have a nice day,
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Tue, Oct 12, 2010 at 12:44 PM, sebb <sebbaz@gmail.com> wrote:
> On 12 October 2010 11:19, Jörg Schaible <joerg.schaible@gmx.de> wrote:
>> sebb wrote:
>>
>>> On 12 October 2010 10:06, Jörg Schaible <joerg.schaible@gmx.de> wrote:
>>>> Hi Simone,
>>>>
>>>> Simone Tripodi wrote:
>>>>
>>>>> Hi all mates,
>>>>> please help me, even if I temporary fixed the compiler issue, I didn't
>>>>> understand why
>>>>>
>>>>> <K,V> void prefill(final KeyedObjectPool<K,V> keyedPool,
final K
>>>>> key, final int count) throws Exception, IllegalArgumentException
>>>>> <K,V> void prefill(final KeyedObjectPool<K,V> keyedPool,
final
>>>>> Collection<K> keys, final int count) throws Exception,
>>>>> IllegalArgumentException
>>>>>
>>>>> when using Object as K so problem is represented. Please help me
>>>>> understand because it's driving me crazy.
>>>>> I noticed Eclipse ignores it, javac from command line not...
>>>>>
>>>>> Many thanks in advance for saving my mental health :)
>>>>> Simo
>>>>
>>>> You cannot trust the Eclipse compiler when using generics. It is a lot
>>>> smarter then Sun's javac. Collection is an Object and therefore Sun's
>>>> compiler does not know for if it should use the method with K or
>>>> Collection<K> if that parameter is an collection of objects :-/
>>>
>>> Is there a solution to this ambiguity, apart from renaming one of the
>>> methods?
>>
>> Sometimes it is possible to resolve the ambiguity by calling the method with
>> explicit generic parameter:
>>
>> foo.<X>method();
>>
>> Depends on the case though.
>
> Even if that would work here, it's not really suitable because it
> would make the API extremely messy to use.
>
> Looks like we might need to rename one of the methods, e.g. use
> prefillAll for the Collection case (as is done with put() and putAll()
> for Maps).
>
> One could treat the Collection as a Object, and detect the Collection
> at run-time, but that would lose the benefit of generics.
>
>> - Jörg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message