On 12 October 2010 11:19, Jörg Schaible <joerg.schai...@gmx.de> wrote: > sebb wrote: > >> On 12 October 2010 10:06, Jörg Schaible <joerg.schai...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
