[JAVA] tricky generics

[voodooless]

Even als eerste vooraf: ja, ik weet dat Hibernate bestaat

Oke, wat ik dus gemaakt heb is een object abstractie van database tabellen. Je kunt dus direct objecten uit een database halen via een query of gewoon via ID. Tabelen en objecten worden aan de hand van annotations aan elkaar gekoppeld, en dat werkt ook heel erg netjes en snel tot nu toe.

Als er meer dan een Object uit komt wil ik een Iterator gebruiken. Echter moet deze iterator van een bepaalt type zijn, dus als we uit de database Kaas objecten halen, dan moet die Iterator<Kaas> zijn. En juist dat krijg ik niet voor elkaar zodat dat de compiler begint te zeuren over type safety.

That's where you come in, maw: hoe krijg ik dat voor elkaar?

Als eerste wat code, de Iterator:

Java:

class QueryItterator<T> implements Iterator{

        public ResultSet rs;
        public Class<T> obj;
        
        public QueryItterator(Class<T> obj,ResultSet rs){
            this.obj = obj;
            this.rs = rs;
        }
        
        public boolean hasNext() {
            try {
                return rs.next();
            } catch (SQLException e) {
                log.error("Exception:", e);
                return false;
            }
        }

        public T next() {
            try {
                return createObject(obj,rs);
            } catch (DAOException e) {
                log.error("Exception:", e);
                return null;
            } 
        }

        public void remove() {
            try {
                rs.deleteRow();
            } catch (SQLException e) {
                log.error("Exception:", e);
            }
        }
        
    }

En nu de code die de Iterator moet terug geven:

Java:

public <T extends Object> Iterator getByQuery(Class<T> obj, String tables,String whereClause,Object... values) throws DAOException {
        
                        .... knip ...

            ResultSet result = resultQuery( SQL query);
            return new QueryIterator(obj,result);
    }

Precies op die return geeft de compiler (of eigenlijk eclipse) dus die warning:

Type safety: The constructor GenericDAO.QueryIterator(Class, ResultSet) belongs to the
raw type GenericDAO.QueryIterator. References to generic type
GenericDAO.QueryIterator<T> should be parameterized

Ik heb al vanalles geprobeerd, maar het wil niet echt helpen. Het is natuurlijk wel slechts een warning, maar als je dit goed voor elkaar krijgt, scheelt, dat flink wat casting in de rest van de code

Dus als jullie tips hebben: graag!

Ben dit weekeind niet echt beschikbaar achter de PC, dus reacties van mijn kant komen pas maandag weer

[Janoz]

Moet je niet eerder in de richting kijken van:

Java:

return new QueryIterator<T>(obj,result);

en dan eigenlijk gewoon de obj parameter weglaten?

[Marcj]

Al eerste kun je de QueryIterator<T> een Iterator<T> laten implementeren:

Java:

class QueryIterator<T> implements Iterator<T>

En dan vervolgens ook voor getByQuery dit doen:

Java:

public <T extends Object> Iterator<T> getByQuery(Class<T> obj,
            String tables, String whereClause, T... values)
            throws DAOException {
    ResultSet result = resultQuery("");
    return new QueryIterator<T>(obj, result);
}

volgens mij zou dit zo ongeveer moeten werken... _{maar is uiteraard niet getest}

[voodooless]

Janoz schreef op vrijdag 20 april 2007 @ 17:29:
Moet je niet eerder in de richting kijken van:

Java:

return new QueryIterator<T>(obj,result);

en dan eigenlijk gewoon de obj parameter weglaten?

Klinkt interessant, maar hoe kan ik dan de Class van T benaderen? Want T.class of T.getClass of zelfs T meegeven in een functie aanroep werkt helaas niet. Zou wel interessant zijn om te weten hoe dat wel moet! En het is natuurlijk ook niet de oplossing voor het probleem

Marcj schreef op vrijdag 20 april 2007 @ 18:28:
En dan vervolgens ook voor getByQuery dit doen:

Java:

    return new QueryIterator<T>(obj, result);

Dat is inderdaad de oplossing . De eerste aanpassing (implements Iterator<T>) is niet eens nodig zo te zien, maar natuurlijk wel wat netter.

Zou mooi zijn als ik er nog achter kon komen hoe die inval van Janoz werkend te krijgen is though

* voodooless vindt dat Sun veel leuke dingen in java 5 heeft ingebakken. Op veel punten een verademing. Eerst denk je: ach, het zal wel allemaal, maar als je dan eindelijk over kunt en ermee aan de gang gaat vind je het toch als snel heel erg handig. Generics en Annotations rule

[ Voor 12% gewijzigd door voodooless op 23-04-2007 08:23 ]

[Confusion]

voodooless schreef op maandag 23 april 2007 @ 08:19:
Klinkt interessant, maar hoe kan ik dan de Class van T benaderen? Want T.class of T.getClass of zelfs T meegeven in een functie aanroep werkt helaas niet. Zou wel interessant zijn om te weten hoe dat wel moet! En het is natuurlijk ook niet de oplossing voor het probleem

Daar is, voorzover ik heb kunnen bedenken/vinden, geen generieke oplossing voor. Een mogelijke oplossing is een abstracte methode getGenericClass aanmaken, die elke afgeleide klasse moet implementeren en die de klasse van de generic parameter teruggeeft. Smerig, maar effectief.

Je kan met behulp van reflection wel bij de generic klasse komen, maar dan moet je bijvoorbeeld weten in de hoeveelste generatie afgeleide klasse je zit en meer van zulke rotzooi. Dat soort code is erg breekbaar.

[Marcj]

voodooless schreef op maandag 23 april 2007 @ 08:19:
[...]


Dat is inderdaad de oplossing . De eerste aanpassing (implements Iterator<T>) is niet eens nodig zo te zien, maar natuurlijk wel wat netter.

Zou mooi zijn als ik er nog achter kon komen hoe die inval van Janoz werkend te krijgen is though

* voodooless vindt dat Sun veel leuke dingen in java 5 heeft ingebakken. Op veel punten een verademing. Eerst denk je: ach, het zal wel allemaal, maar als je dan eindelijk over kunt en ermee aan de gang gaat vind je het toch als snel heel erg handig. Generics en Annotations rule

Als je generics wilt gebruiken zou ik het ook overal gaan gebruiken. Als je het soms wel en soms niet doet, kun je een aantal hele lastige problemen tegen komen. Ik vind zelf dat deze tutorial generics wel goed uitlegd.

[voodooless]

Confusion schreef op maandag 23 april 2007 @ 08:33:
Daar is, voorzover ik heb kunnen bedenken/vinden, geen generieke oplossing voor. Een mogelijke oplossing is een abstracte methode getGenericClass aanmaken, die elke afgeleide klasse moet implementeren en die de klasse van de generic parameter teruggeeft. Smerig, maar effectief.

Met Generics wil je juist geen afgeleide klasse maken Het zou wel werken natuurlijk, maar zoals gezegd, het is smerig, en je moet een afgeleide maken. Niet erg handig dus. Het is dan nog beter om de Class met de constructor mee te geven.

Ik ga eens kijken wat ik met reflection kan doen

Hier nog een leuke FAQ: http://www.angelikalanger...ns/ProgrammingIdioms.html , buiten de obvious dingen echter geen oplossing. Denk dat ik voorlopig nog maar blijf hangen op die constructor, werkt immers prima.

[ Voor 19% gewijzigd door voodooless op 23-04-2007 09:13 ]

[Verwijderd]

voodooless schreef op maandag 23 april 2007 @ 08:46:
Ik ga eens kijken wat ik met reflection kan doen

Generics omzeilen

[voodooless]

Verwijderd schreef op maandag 23 april 2007 @ 10:12:
Generics omzeilen

Ik hoopte met reflection het runtime type van de generieke classe te kunnen achterhalen. Jammer maar helaas is me dat (nog) niet gelukt.

[Verwijderd]

voodooless schreef op maandag 23 april 2007 @ 10:16:
Ik hoopte met reflection het runtime type van de generieke classe te kunnen achterhalen. Jammer maar helaas is me dat (nog) niet gelukt.

Runtime is het niets anders dan een cast, je ziet er geloof ik ook neits van terug in de bytecode

[Alex Picard]

Generics bestaan alleen voor de compiler om type-safety te enforcen... Vanwege compatibiliteit en performance bestaan generics niet at runtime, en worden generic aanroepen overal van typecasts voorzien.

De enige winst voor de programmeur is dat je minder fouten maakt door de strenge typecontrole en dat je niet steeds zelf je types hoeft te casten.

[voodooless]

Tja, dat dacht ik al. Erg jammer, want @ runtime zou je er ook nog leuke dingen mee kunnen doen

[Salandur]

volgens mij heb je daar annotations voor

[voodooless]

Salandur schreef op maandag 23 april 2007 @ 10:51:
volgens mij heb je daar annotations voor

Nee, die zijn leuk voor andere dingen. Ik gebruik ze om aan te geven op welke tabel een object mapt en welke velden bij de getters en settere horen. Fun stuff

Wat ik nu juist wilde is die

Java:

public QueryIterator(Class<T> obj,ResultSet rs)

obj parameter vermeiden door direct T te gebruiken @ runtime, net als Janoz in zijn eerste reply voorstelt. Dat kun dus gewoon niet!

[ Voor 12% gewijzigd door voodooless op 23-04-2007 11:00 ]

[Janoz]

Kun je niet gewoon:

Java:

public QueryIterator(T obj,ResultSet rs)

gebruiken en dan daarbinnen obj.getClass() aanroepen? Nadeel is dat je dan wel een instantie moet maken, maar dan hoef je niet met allerlij reflection aan de gang te gaan.

[voodooless]

Die instantie wil ik juist niet aanmaken, want dat doet die createObject methode al voor me. Die iterator moet immers ook meerdere instantie van dat object aanmaken, vandaar dat ik ook enkel en alleen het type aangeef.

Je zegt dus gewoon tegen het DAO object dat je uit de database een berg Objecten dan type X wil, en de rest gaat vanzelf

[Janoz]

Waar komt die createObject vandaan? Eventueel zou je die ook nog aan kunnen passen.

[voodooless]

Die iterator is een inner class (ja, ugly, maar check maar eens wat Sun code, staat er vol mee ), en createObject zorgt er dus voor dat het object aangemaakt wordt en gevuld wordt met de data uit de resultset.

[Verwijderd]

voodooless schreef op maandag 23 april 2007 @ 11:42:
Die iterator is een inner class (ja, ugly, maar check maar eens wat Sun code, staat er vol mee )

Wat is er zo 'ugly' aan een dergelijke inner-class?

[voodooless]

Verwijderd schreef op maandag 23 april 2007 @ 13:07:
Wat is er zo 'ugly' aan een dergelijke inner-class?

Aan dergelijke dergelijke inner-classes is op zich niets ugly. Immers wil je van buiten ook niet zien welke iterator het ding terug geeft.

[Janoz]

Zou je de source van createObject kunnen posten? Ik krijg namelijk een beetje het vermoeden dat dit probleem op een iets andere plek eleganter op te lossen is. (maar daarin kan ik het uiteraard mis hebben!)

[Verwijderd]

voodooless schreef op maandag 23 april 2007 @ 13:13:
Aan dergelijke inner-classes is op zich niets ugly. Immers wil je van buiten ook niet zien welke iterator het ding terug geeft.

Moet het daarvoor dan een inner-class zijn om te verbergen welke implemenatie van een Iterator gebruikt wordt?

[voodooless]

Janoz schreef op maandag 23 april 2007 @ 13:16:
Zou je de source van createObject kunnen posten? Ik krijg namelijk een beetje het vermoeden dat dit probleem op een iets andere plek eleganter op te lossen is. (maar daarin kan ik het uiteraard mis hebben!)

Die code wil ik liever niet prijsgeven. Ik kan je wel vertellen waar het op neer komt:

- maak instantie van Object aan, constructor van het object hoort hierbij geen argumenten te hebben
- ga alle get methode langs en check hiervan de annotations op kolom namen die corresponderen met kolommen van de database tabel.
- indien kolom present, haal value (met correcte type natuurlijk) uit de ResultSet, en roep de corresponderende setter aan.
- return gevulde object

Op die manier vul ik dus mijn object met de waarde van de resultset. Ik han natuurlijk ook alle setters aflopen, maar dan krijg ik ergens anders in mijn code problemen. Ik heb er dus voor gekozen om de annotations bij de getters te zetten. Ik had ook de setters kunnen gebruiken natuurlijk. 't is om het even... Anyway, met flink wat caches is dit behoorlijk snel en merk je nagenoeg geen verschil in snelheid met het handmatig vullen objecten uit een recordset.

Verwijderd schreef op maandag 23 april 2007 @ 13:18:
Moet het daarvoor dan een inner-class zijn om te verbergen welke implemenatie van een Iterator gebruikt wordt?

Natuurlijk niet. Komt nog bij dat die iterator enkel en alleen door de betreffende outerklasse gebruikt wordt, ik zie dus geen rede waarom ik er een geen inner classe van zou maken.

[ Voor 14% gewijzigd door voodooless op 23-04-2007 13:25 ]

[Verwijderd]

voodooless schreef op maandag 23 april 2007 @ 13:23:
Natuurlijk niet. Komt nog bij dat die iterator enkel en alleen door de betreffende outerklasse gebruikt wordt, ik zie dus geen rede waarom ik er een geen inner classe van zou maken.

Nee ik zie ook geen reden waarom het niet een inner-class zou moeten kunnen mogen willen hebben zijn (off: leuke taal dat NL). Maar jij riep dat het 'ugly' was, dus ik vroeg me dan af wat je er op aan te merken had. Klaarblijkelijk dus niets

[voodooless]

Verwijderd schreef op maandag 23 april 2007 @ 13:29:
Klaarblijkelijk dus niets

Ik dit geval niet nee

[Janoz]

Aangezien ik mezelf ook nog iets meer wil verdiepen in Generics ben ik eens ff wat met dit probleem wezen pielen. Ik heb iig de volgende link gevonden die handig zou kunnen zijn:

http://serdom.szn.pl/ser/...hout-using-class-literal/

[voodooless]

Dat soort dingen had ik ook al gevonden, maar hebben bij mij geen nut, aangezien het bovenliggende Object niet echt generiek is maar meerdere verschillende objecten kan uitspugen. Voor de iterator zou iets dergelijk nog kunnen, echter aangezien ik die Class toch al nodig heb ik bovenliggende object maatk het eigenlijk ook niet veel meer uit.

[Janoz]

Als je de aanroep aanpast van obj naar obj.class ben je er in principe al. Het is inderdaad even een omweg, maar dan kun je het object vervolgens wel instantieren.

[voodooless]

Ik werk toch ook steeds met de Class Of zie ik het nu fout?

[Janoz]

Hmm, ik raak blijkbaar wat in de war omdat je obj gebruikt terwijl dat eigenlijk een class is (bij obj vermoed ik een instantie van ipv de class zelf)

maar dan zie ik het probleem even niet meer. Je kunt van een class toch gewoon getInstance() opvragen om hem te instantieren?

[voodooless]

Janoz schreef op maandag 23 april 2007 @ 14:43:
maar dan zie ik het probleem even niet meer. Je kunt van een class toch gewoon getInstance() opvragen om hem te instantieren?

Natuurlijk Daar lag het probleem ook niet (als je al over een probleem kon spreken). Het "probleem" lag bij de iterator die ik eventueel wat mooier wilde hebben. Maar dat gaat dus niet.