Díky všem za vysvětlení :). Tak trochu jsem rád, že to je chyba jazyka,
i když bych byl radši, kdyby nebyla :).
Každopádně mě ani tak nešlo o nějaké kontroly, natož kontroly za
Runtime, apod. (ne že by to nebylo super).
Prostě mě jen vadila ta kosmetická vada, že když mám něco vlevo od
rovnítka a když to samé použiji vpravo, tak očekávám, že nebude
překladač prudit s warningy, apod.
Šlo mi čistě o tu kosmetiku - nerad ignoruji podobná hlášení. A hlavně
jsem si chtěl být jistý, že nedělám jen chybu v zápisu.
Taky mi šlo o to, že jsem autorem té factory-metody na naší platformě a
tak se mi nelíbí, když našim vývojářům dávám příklady použití, které
jsou pak plné warningů a zavání, jako kdyby programovali něco proti
pravidlům toho jazyka.
Podědit tu třídu je zajímavý nápad, ale touto cestou nepůjdu (zbytečně
mnoho kódu navíc prakticky bez užitku, to ty genericy pak nemusíme
používat vůbec) , hold v tomto případě budou muset vyjímečně použít:
@SuppressWarnings("unchecked")
Cache<String, String> cache =
UESComponentFactory.getComponent(Cache.class, TEST_CACHE);
Ale ještě jednou všem díky, hezký zbytek dne
Petr
Dne 19.9.2011 14:37, Petr Balat napsal(a):
dobrý den,
bohužel java překladač neumí Kovarianci a kontravarianci
http://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)
<http://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29>
(viz google -> Covariance a Contravariance) proto bude java varovat
při výrazech typu
Cache<String, String> cache = ComponentFactory.getComponent(Cache.class)
nebo např. nepůjde zkompilovat Iterable<Object> o = new
ArrayList<String>();
ale bohužel se i při překladu informace o typu v parametru ztratí
takže vás ani runtime neochrání pro vložení jiných typů než jsou
definované.
Předpokládám ale že Vám jde o typovou kontrolu při kompilaci kde někde
pouzijete Class<Cache<String,String>> cls=...;
Cache<String, String> = cls.createInstance();
můžete vytvorit tridu ktera bude dedit po Cache<String, String> potom
Vam to kompilator vezme.
Ale myslím si že si tím nic nezachráníte (kdekoliv muze nekdo
Cache<string, string> pretypovat na Cache a vlozit jiny typ a spadne
to az pri vyzvednuti objektu a jeho typ) ale uměle budou vytvořeny
zbytečné nové třídy takže bych se s varováním smířil nebo použil
pokročilejší programovací jazyk jako např. c# :-)
S pozdravem
Petr Balat
2011/9/19 Petr Novak <[email protected] <mailto:[email protected]>>
Zdravím konferenci,
narazil jsem na problém s generic a nevím, jestli je problém jen
v mé hlavě, nebo v javě a google mi zatím moc nepomohl, protože
ani nevím jak se řádně zeptat.
Problém je s následujícím kouskem kódu:
Class<Cache<String,String>> cls = Cache.class; // nelze
zkompilovat, eclipse mi nabízí, abych Class<Cache<String,String>>
převedl jen na Class<Cache>, ale to pak má warning, že používám
RAW typy, což ani nechci :).
Myslel jsem, že půjde zapsat
Class<Cache<String,String>> cls = Cache<String,String>.class;
//ale toto nelze kompilovat už vůbec, řve to, že Cache není
definována a že ty závorky tam nemají být a kdo ví co ještě.
Definice rozhraní cache je jednoduchá: public interface Cache<K,
V>{....}
Původní problém je trochu jiný, ale důsledek stejný, ve
skutečnosti potřebuji:
Cache<String, String> cache =
ComponentFactory.getComponent(Cache.class, CACHE_NAME); //toto
ale opět hází warning
definice té metody je:
public static <T> T getComponent(final Class<T> compClass, final
String compName);
čekal jsem možnost použití
Cache<String, String> cache =
UESComponentFactory.getComponent(Cache<String,String>.class,
TEST_CACHE); //ale jak plyne z výše uvedeného, toto nelze kompilovat
Jediné řešení, které funguje compilačně a bez warningu je:
@SuppressWarnings("unchecked")
Cache<String, String> cache =
UESComponentFactory.getComponent(Cache.class, TEST_CACHE);
ale to se mi nelíbí.
Nemáte někdo nějaký nápad, jak v javě zapsat správně
Cache<String,String>.class ? Klidně to můžete zkusit pro
Map<String,String> dopadne to stejně.
Díky za veškeré podněty
Petr
--
Petr
