[Java] če naredim razred generičen, dobim milijon napak

Malo hecno , ampak. Imam en razred, nekaj takega :
(zakaj ni gumba "St.koda" ? )

public abstract class MojaRazred extends NekiRazred {
...
 protected Map<String, Object> mapa;
...

Ki vsebuje kup metod, polj itd..
Imam tudi kup izpeljanih razredov. In lepo deluje.

Ker pa imam zdaj precej cast-anja, sem mislil malo generike uporabit.

Ampak če spremenim malenkost (dodal le "<T>" v prvo vrstico) :

public abstract class MojRazred <T> extends NekiRazred {
...
 protected Map<String, Object> mapa;
...

..dobim milijon napak v podrazredih.
Kolko sem razumel, generične verzije razredov so kompatibilne nazaj z negeneričnimi. (primer Map in Map<K,V>, stara koda, ki uporablja le Map, čist lepo dela z novo generično verzijo mape).
Še toliko bolj je čudno, ker parametra T zaenkrat sploh nikjer nisem uporabil.

Za začetek bom navedel en warning, ki se mi s tem pojavi. V enem podrazredu od MojRazred imam :

public class PodRazred extends MojRazred
  @Override
    protected void nekaj() throws Exception {
        super.nekaj();
        mapa.put("foo", true); // warning !

Za označeno vrstico mi da opozorilo :

Type safety: The method put(Object, Object) belongs to the raw type Map. References to generic type Map<K,V> should be parameterized

Kaj s tem hoče povedat ??? Kak naj popravim ?

Zdaj pa k napakam. V PodRazred imam tudi :

   @Override
    protected void ojoj(List<Object> spisek, Object obj) {

To da napako :

The method ojoj(List<Object>, Object) of type PodRazred must override a superclass method


Seveda je v superklasi (MojRazred) stvar lepo definirana:

 protected void ojoj(@SuppressWarnings("unused")
    List<Object> spisek, @SuppressWarnings("unused")
    Object testObject) {
        // don't do anything, let subclasses override
    }

Kaj mu fali ? Sicer se napake znebim, če odstranim anotacijo @Override, ampak potem ostane dvom, da superklasa ne bo klicala te, ker kao ni ista. Razen tega ne glede na @Override ima ena podpodklasa naslednjo napako:

Name clash: The method ejej(List<Object>, Object) of type PodRazred has the same erasure as ejej(List<Object>, Object) of type MojRazred but does not override it


Koda:

public class PodPodRazred extends PodRazred{
   @Override
    protected Class getFoobar() { // to je ena abstract metoda v MojRazred
        return Krneki.class;
    }
}

bojkodane ne more biti isto dekaracije metod rabijo generični označevalec. v ostalem compiler ne more vedet v kaj razviti kodo. sem skoraj prepican da dobivaš kake trke med referianimi tipi? sicer nisem java guru ampak generiki so nekako tako zadeva , da se substituira glede na uporabljan tip T(pa uni jebeni uklepaji, dejte ze enkat nardit knof za kodo) z tistim kateri je konzumiral generika.

noraguta, a lahko to ponoviš, na razumljiv način ?

kopernik:
- "Odvisno kaj sploh hočeš narediti."

Uporabiti prednosti generikov, ampak na nazaj kompatibilen način (torej brez spreminjanja že napisanih "uporabnikov" omenjene kode). Beri: kup že napisane kode ne bom spreminjal, ampak bom generike izkoristil pri na novo napisani kodi. Saj sem dal primer. Novi Vector je generičen, ampak stara koda, ki uporablja stari, negeneričen Vector še vedno dela, brez sprememb.

- "Če podrazredi niso generični, potem moraš pri razširjanju povedati kakšnega tipa je parameter v superclassu"

Ne, ne rabim. Temu se reče kompatibilnost nazaj. Če uporabljam razred, ki ni generičen, potem pa nova verzija je, ne rabim jaz svojo kodo nič spreminjat. Lahko, ni pa nujno. Vsaj tak sem jaz razumem omenjeno kompatibilnost nazaj generikov.

- "In zakaj imaš annotatione @SuppressWarnings("unused") v tisti metodi ?"
To itak nima veze s tem problemom. Razen tega, a ni očitno ? Gre za "stub" metodo, ki ne uporablja ta parameter (ker ne uporablja sploh nič, je NO-OP), namenjena pa je temu, da jo izpeljan razred overrajda in pri tem uporabi te parametre.

Ne vem, kak ve, ampak očitno nekak ve. Sem namreč naredil novi podrazred in lepo dela. Tak :

public class PodRazred2 extends MojRazred {

    public void foo() {
        System.out.println("A kompajler cita misli ????");
    }

}

Razen tega, če bi sam prebral tutoriale, ki jih omenjaš, bi vedel, da v času, ko se prevaja PodRazred2, MojRazred že preveden, in ker se vsa umetnost generikov pri prevajanju izbriše (glej pod erasure), kompajler nima kaj razmišljat o T, ker takrat T več ne obstaja.

Kakorkoli, v mojem projektu sem vse fajle popravil na roko in vse dela, tak da ni nobene sile...

Ampak s tem se ne boš rešil warningov. A ni bil to problem ?

Priporočam tudi ogled izvorne kode jdk 1.5, npr. collection frameworka, kjer je precej parametriziranih vmesnikov in razredov, pri čemere je hierarhija kar razvejana. Boš videl, kako extendajo parametrizirane razrede.

EDIT: quikee, to je res in ravno to so mnogi spljuvali pri uvedbi parametrizacije v Javi, ker se v mnogih primerih koda bolj zaplete, namesto da bi se poenostavila. V C++ lahko na parametru kličeš karkoli, medtem ko v Javi največ tisto, kar je v osnovnem tipu (v tem primeru Object).