[Java/Android] HashMap overschrijft eigen waardes

[NMe]

Ik ben bezig met het schrijven van een Android-app waarbij ik data uit een aantal verschillende bronnen (XML, database, enz) moet kunnen halen. Ik gebruik een HashMap als tussenlaag om data door te kunnen geven van de ene method naar de andere; daar zijn zo zijn redenen voor maar daar ga ik in dit topic liever niet op in aangezien dat wel erg offtopic is.

Anyway, ik doe het volgende:

Java:

NodeList trackNodes = root.getElementsByTagName("track");
List<HashMap<String, String>> tracks = new ArrayList<HashMap<String, String>>();
for (int j = 0; j < trackNodes.getLength(); j++) {
    Node item = trackNodes.item(j);
    NodeList trackProperties = item.getChildNodes();
    HashMap<String, String> track = new HashMap<String, String>();
    
    for (int k = 0; k < trackProperties.getLength(); k++) {
        Node trackProperty = trackProperties.item(k);
        String tpName = trackProperty.getNodeName();
        if (trackProperty.hasChildNodes())
            track.put(tpName.toLowerCase(), trackProperty.getFirstChild().getNodeValue());
    }
    tracks.add(track);
}

In het kort: ik loop door alle <track> tags in mijn XML-document heen en voeg voor elk item een HashMap (track) toe aan een ArrayList (tracks). Debuggen toont aan dat hij inderdaad allevier de child-elements van mijn track-element vindt, echter na afloop van deze loop slaat hij slechts twee van de vier elementen op in de HashMap.

Wat er gebeurt bij het debuggen: track.put() zet het eerste child-element dat hij tegenkomt neer op positie 2 (de derde positie dus) van de interne array van de HashMap. Op de tweede iteratie van de binnenste loop doet hij dat echter nog eens: hij overschrijft de waarde die in de vorige iteratie op positie 2 is neergezet. Tijdens de derde iteratie gebruikt hij positie 3 voor het opslaan van dit child-element, en voor de vierde property gebruikt hij weer positie 2. Dit resulteert erin dat de HashMap waarvan ik zou verwachten dat hij 4 entries heeft er maar 2 heeft.

Kent iemand dit probleem? En wat zou ik moeten doen om het op te lossen?

[CoolGamer]

HashMap kan geen meerdere waarden voor een key bevatten. Je zal dus in de HashMap een List moeten stoppen zodra je meerdere waarden voor een key wilt hebben.

[ Voor 9% gewijzigd door CoolGamer op 18-09-2010 15:33 ]

[HuHu]

TheCoolGamer schreef op zaterdag 18 september 2010 @ 15:27:
HashMap kan geen meerdere waarden voor een key bevatten. Je zal dus in de HashMap een List moeten stoppen zodra je meerdere waarden voor een key wilt hebben.

Daarvoor kun je dan een HashBag gebruiken.

[CoolGamer]

HuHu schreef op zaterdag 18 september 2010 @ 15:46:
[...]

Daarvoor kun je dan een HashBag gebruiken.

Dan lijkt mij een MultiMap makkelijker, aangezien je daar elementen aan de hand van een key kan toevoegen. Een HashBag heeft geen key.

[NMe]

TheCoolGamer schreef op zaterdag 18 september 2010 @ 15:27:
HashMap kan geen meerdere waarden voor een key bevatten. Je zal dus in de HashMap een List moeten stoppen zodra je meerdere waarden voor een key wilt hebben.

Het zijn verschillende keys, da's het vreemde. Maar inderdaad, dat was ik vergeten erbij te vermelden.

[Woy]

Zou het misschien kunnen doordat je eerst toLowerCase doet dat de keys toch hetzelfde zijn? Het lijkt me erg sterk dat er een Bug in de equals of hashCode van de string class zit.

[Kwistnix]

Huh, je weet zeker dat Node.getNodeName() teruggeeft wat je verwacht dat het teruggeeft (is afhankelijk van het type Node) en dat dat vier verschillende String waarden en daarmee unieke keys oplevert?
Ik kan mij moeilijk voorstellen hoe het anders fout kan gaan eigenlijk.

[Gleighton]

[..]Hier stond onzin.
Heb net een half uur zitten staren naar mn code waarom het niet werkt, bleek ik geen == gebruikt te hebben waar dat wel moest. *schaam*, ja * Gleighton is dus noob.

[ Voor 78% gewijzigd door Gleighton op 18-09-2010 22:33 ]

[CoolGamer]

Gleighton schreef op zaterdag 18 september 2010 @ 20:40:

Beide stukjes code doen hetzelfde.Dus dat is het niet.

[NMe]

Woy schreef op zaterdag 18 september 2010 @ 18:47:
Zou het misschien kunnen doordat je eerst toLowerCase doet dat de keys toch hetzelfde zijn? Het lijkt me erg sterk dat er een Bug in de equals of hashCode van de string class zit.

De lowercase-versies van de strings die ik binnenkrijg zijn golftrackid, golftrackname, difficultylevel en holes, in die volgorde. Dat gebeurt ook netjes zoals verwacht en alsnog overschrijft golftrackname eerst de golftrackid, vervolgens wordt difficultylevel apart opgeslagen en overschrijft holes weer de golftrackname. Zowel de keys als ook de values zijn eigenlijk voor alle tracks die ik binnenkrijg verschillend.

Verder denk ik ook niet dat er een bug in het framework zit op dit gebied, zeker aangezien dit mijn eerste grote Java-project is. Maar ik zou graag uitvinden waar de bug in mijn code dan zit.

Mocht het enige vragen beantwoorden, dit is een voorbeeld van de gebruikte XML: http://crew.tweakers.net/NMe/prg/course.xml

[ Voor 6% gewijzigd door NMe op 18-09-2010 21:40 ]

[Woy]

Wat krijg je als return waarden als je voor het inserten met containsKey kijkt of de key al aanwezig is. Probeer gewoon eens de key te outputten, het result van containsKey voor en na de insert, en de value van size() voor en na de insert.

Als de code die je gepost hebt exact is wat je gebruikt en je zeker weet dat het andere keys zijn, dan zie ik niet waar het mis kan gaan.

[pedorus]

Tsja, als ik de code uittest onder jre6 dan werkt het gewoon...

Java:

import java.io.*;
import java.util.*;
import org.w3c.dom.*;
import javax.xml.parsers.*;

public class HashTest {
    public static void main(String[] args) throws Exception {
        DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
        DocumentBuilder db = dbf.newDocumentBuilder();
        Document root = db.parse(new File("course.xml"));

Natuurlijk heeft Google een eigen implementatie, maar het lijkt me sterk dat het daar zoveel anders werkt. Dat zou dus betekenen dat iets als

Java:

            HashMap<String, String> track = new HashMap<String, String>();
            track.put("golftrackid", "1");
            track.put("golftrackname", "2");
            track.put("difficultylevel", "3");
            track.put("holes", "4");

misgaat?

[Erik Jan]

Klinkt als een optimalisatie / compiler probleem, wat is je setup?

[NMe]

Woy schreef op zaterdag 18 september 2010 @ 23:23:
Wat krijg je als return waarden als je voor het inserten met containsKey kijkt of de key al aanwezig is. Probeer gewoon eens de key te outputten, het result van containsKey voor en na de insert, en de value van size() voor en na de insert.

containsKey geeft vóór de put netjes false en na de put netjes true terug. Ook de size loopt blijkbaar netjes op van 0 naar 4. En tóch overschrijft hij mijn key/value-pairs?

Als de code die je gepost hebt exact is wat je gebruikt en je zeker weet dat het andere keys zijn, dan zie ik niet waar het mis kan gaan.

Ik ook niet, vandaar dit topic.

pedorus schreef op zaterdag 18 september 2010 @ 23:42:
Natuurlijk heeft Google een eigen implementatie, maar het lijkt me sterk dat het daar zoveel anders werkt. Dat zou dus betekenen dat iets als

Java:

            HashMap<String, String> track = new HashMap<String, String>();
            track.put("golftrackid", "1");
            track.put("golftrackname", "2");
            track.put("difficultylevel", "3");
            track.put("holes", "4");

misgaat?

Dat doet inderdaad precies wat er bij mij ook gebeurt. track.table[0] en track.table[1] blijven null, track[2] wordt eerst gevuld met het id en de naam en later met holes, track.table[3] wordt gevuld met het difficultylevel. En de table krijgt niet meer dan die 4 keys.

Erik Jan schreef op zondag 19 september 2010 @ 00:16:
Klinkt als een optimalisatie / compiler probleem, wat is je setup?

Wat wil je precies weten? Ik zit op Eclipse Galileo. 3.5 is dat geloof ik, maar het about-scherm geeft geen versienummer dus dat weet ik niet 100% zeker. Verder heb ik de meest recente Android plugin, voor zover dat relevant is. Andere plugins of legacy settings heb ik niet; ik heb Eclipse speciaal voor dit project geïnstalleerd. De HashMap die ik gebruik is gewoon java.util.HashMap, geen Google-implementatie daarvan.

[pedorus]

NMe schreef op zondag 19 september 2010 @ 01:10:
Dat doet inderdaad precies wat er bij mij ook gebeurt. track.table\[0] en track.table\[1] blijven null, track\[2] wordt eerst gevuld met het id en de naam en later met holes, track.table\[3] wordt gevuld met het difficultylevel. En de table krijgt niet meer dan die 4 keys.

Je snapt Google's implementatie van HashMap niet, deze is anders dan die van Sun/Oracle. Bij Google is dit een array die een single-linked list bevat. Klik maar eens op het ding zelf, en Eclipse geeft netjes "{holes=4, golftrackname=2, golftrackid=1, difficultylevel=3}" aan in mijn voorbeeld.

Wat wil je precies weten?

De SDK: Andriod 2.2 api 8 r2

[NMe]

pedorus schreef op zondag 19 september 2010 @ 02:16:
[...]

Je snapt Google's implementatie van HashMap niet, deze is anders dan die van Sun/Oracle. Bij Google is dit een array die een single-linked list bevat. Klik maar eens op het ding zelf, en Eclipse geeft netjes "{holes=4, golftrackname=2, golftrackid=1, difficultylevel=3}" aan in mijn voorbeeld.

Bij mij geeft Eclipse {null,null,"difficultylevel=3","holes=4"} aan. Sowieso, hoe kan Google invloed hebben als ik java.util.HashMap gebruik? Dat is toch gewoon de implementatie van Sun? Tenzij ik naar iets anders aan het kijken ben dan jij; wat inspecte jij hier? track.table? Ik wel in elk geval.

De SDK: Andriod 2.2 api 8 r2

Ik dev voor Android 1.6, en da's uit het hoofd API level 4, geloof ik.

[Erik Jan]

Aah het probleem is dus dat je teveel met de debugger naar de private attributen van de HashMap implementatie zit te kijken Als je itereert over de HashMap zal je zien dat alles er toch echt wel in zit.

Die table met null waarden maakt uit onderdeel uit van de datastructuur zelf en zal implementatie-specifieke objecten bevatten, niet per se direct de Strings die je erin hebt gestopt.

[Soultaker]

Maar de hamvraag is dus: als je over de map itereert op het eind, zitten dan alle key/value pairs er in of niet? Zo ja, dan is 't een IDE fail, en is er verder weinig aan de hand.

[Toolskyn]

NMe schreef op zondag 19 september 2010 @ 02:50:
[...]

Bij mij geeft Eclipse {null,null,"difficultylevel=3","holes=4"} aan. Sowieso, hoe kan Google invloed hebben als ik java.util.HashMap gebruik? Dat is toch gewoon de implementatie van Sun?[...]

Google heeft een volledig eigen implementatie gemaakt met syntax die 'toevallig' op java lijkt. Ook hebben ze een groot gedeelte van de standaardlibrary van java gekopieerd qua interface, maar de implementatie van Dalvik + Android SDK is volledig door google gemaakt.

[Woy]

NMe schreef op zondag 19 september 2010 @ 01:10:
[...]

containsKey geeft vóór de put netjes false en na de put netjes true terug. Ook de size loopt blijkbaar netjes op van 0 naar 4. En tóch overschrijft hij mijn key/value-pairs?

Dan lijkt het er inderdaad op dat het een debug(ger) probleem is. Probeer gewoon eens over de keys/values te itereren nadat hij gevuld is.

[YopY]

quote: Toolskyn

Ook hebben ze een groot gedeelte van de standaardlibrary van java gekopieerd qua interface

Dan zou, mits die interface goed gedocumenteerd is, de uitkomst van alle operaties ook precies hetzelfde moeten zijn als die van de standaard Java implementaties daarvan. Qua performance en interne werking kunnen ze idd afwijken en bugs bevatten.

@topic, wat zegt de unit test die je hierbij geschreven hebt? (als ik de reacties hierboven lees is dit een geval teveel naar de debugger kijken, ipv het daadwerkelijke resultaat bekijken. Debuggen doe je pas als er hele gekke dingen gebeuren)

[Herko_ter_Horst]

NMe schreef op zondag 19 september 2010 @ 01:10:

Dat doet inderdaad precies wat er bij mij ook gebeurt. track.table\[0] en track.table\[1] blijven null, track\[2] wordt eerst gevuld met het id en de naam en later met holes, track.table\[3] wordt gevuld met het difficultylevel. En de table krijgt niet meer dan die 4 keys.

Zoals al gezegd: track.table[n], sinds wanneer staat dat op de interface van Map (of HashMap)? Wat gebeurt er als je in plaats daarvan gewoon track.get(key) doet? Of itereert over de values()?

[NMe]

YopY schreef op zondag 19 september 2010 @ 11:41:
[...]

Dan zou, mits die interface goed gedocumenteerd is, de uitkomst van alle operaties ook precies hetzelfde moeten zijn als die van de standaard Java implementaties daarvan. Qua performance en interne werking kunnen ze idd afwijken en bugs bevatten.

@topic, wat zegt de unit test die je hierbij geschreven hebt? (als ik de reacties hierboven lees is dit een geval teveel naar de debugger kijken, ipv het daadwerkelijke resultaat bekijken. Debuggen doe je pas als er hele gekke dingen gebeuren)

Dat is het probleem dus juist: ik wilde de resultaten van deze HashMap gebruiken maar in plaats van dat mijn GolfTrack-object vanuit een latere method netjes naam en ID overnam bleven deze null. Ik dacht dat hierheen getraceerd te hebben, vandaar dat ik er zoveel waarde aan hechtte. Ik moet wel bekennen dat ik inderdaad nog niet geprobeerd heb om binnen de method over de HashMap heen te loopen om te checken of hij alle waardes bevat die ik dacht dat hij bevatte, dat ga ik zodra ik mijn werklaptop opstart meteen proberen.

[Remus]

NMe schreef op zondag 19 september 2010 @ 02:50:
[...]

Bij mij geeft Eclipse {null,null,"difficultylevel=3","holes=4"} aan. Sowieso, hoe kan Google invloed hebben als ik java.util.HashMap gebruik? Dat is toch gewoon de implementatie van Sun? Tenzij ik naar iets anders aan het kijken ben dan jij; wat inspecte jij hier? track.table? Ik wel in elk geval.

Het gedrag en interface java.util.HashMap is gedefineerd in de Java 'standaard', maar iedere JVM maker levert zijn eigen implementatie. In geval van Android komt de implementatie uit project Harmony en is dus niet van Sun. Probeer het ook eens in een niet Android (maar een standaard Java) project, mogelijk is het een bug in de Google/Project Harmony implementatie van java.util.HashMap (al lijkt mij dat erg sterk).

[Soultaker]

NMe schreef op zondag 19 september 2010 @ 13:26:
Ik moet wel bekennen dat ik inderdaad nog niet geprobeerd heb om binnen de method over de HashMap heen te loopen om te checken of hij alle waardes bevat die ik dacht dat hij bevatte, dat ga ik zodra ik mijn werklaptop opstart meteen proberen.

Is je laptop al geboot? Wat is het resultaat? Vertel NMe, we willen het weten, desnoods betalen we bij!

[pedorus]

NMe schreef op zondag 19 september 2010 @ 02:50:
Bij mij geeft Eclipse {null,null,"difficultylevel=3","holes=4"} aan. [...] Tenzij ik naar iets anders aan het kijken ben dan jij; wat inspecte jij hier? track.table? Ik wel in elk geval.

Nee, track zelf. Als ik track.table bekijk, dan krijg ik [null, null, holes=4, difficultylevel=3] (toch een net iets andere versie?). Dat is op zich logisch omdat een node van een single linked list zijn sleutel+'='+waarde geeft, en een array van dat soort nodes dus alleen de eerste waardes laat zien.

Ik dev voor Android 1.6, en da's uit het hoofd API level 4, geloof ik.

Die versie kent geen .table maar een .elementData. Dus dan debug je met een nieuwere versie ofzo..

[Herko_ter_Horst]

Overigens ben ik inmiddels wel benieuwd naar de reden voor de HashMap i.p.v. een GolfTrack object met de juiste velden/getters/setters?

[NMe]

Remus schreef op maandag 20 september 2010 @ 08:21:
[...]

Het gedrag en interface java.util.HashMap is gedefineerd in de Java 'standaard', maar iedere JVM maker levert zijn eigen implementatie. In geval van Android komt de implementatie uit project Harmony en is dus niet van Sun. Probeer het ook eens in een niet Android (maar een standaard Java) project, mogelijk is het een bug in de Google/Project Harmony implementatie van java.util.HashMap (al lijkt mij dat erg sterk).

Weer wat geleerd, thanks.

Soultaker schreef op maandag 20 september 2010 @ 12:09:
[...]

Is je laptop al geboot? Wat is het resultaat? Vertel NMe, we willen het weten, desnoods betalen we bij!

Ik heb er vandaag de tijd niet voor gehad. Nu de betaversie van de software waar deze vraag over ging afgelopen zaterdag public is gegaan is de druk even van de ketel en kon ik wat andere dingen oppakken die al een tijdje lagen.

pedorus schreef op maandag 20 september 2010 @ 15:34:
[...]

Nee, track zelf. Als ik track.table bekijk, dan krijg ik [null, null, holes=4, difficultylevel=3] (toch een net iets andere versie?).

Nee, je hebt gelijk, dat zag ik ook. Ik tikte mijn waardes even uit het hoofd en maakte daarbij een foutje in de volgorde.

Overigens kan ik track zelf niet inspecten in Eclipse? Het enige dat ik dan te zien krijg is een of andere vage string representation van het object, zonder verdere info over de inhoud.

Die versie kent geen .table maar een .elementData. Dus dan debug je met een nieuwere versie ofzo..

We zijn als Android 2.0-project begonnen en hebben laterna het zaakje aangepast zodat het op 1.6 zou kunnen draaien. Is het mogelijk dat daarbij iets mis gaat waardoor de debugger in de war raakt? If not, dan weet ik het ook niet verder.

Herko_ter_Horst schreef op maandag 20 september 2010 @ 17:26:
Overigens ben ik inmiddels wel benieuwd naar de reden voor de HashMap i.p.v. een GolfTrack object met de juiste velden/getters/setters?

Omdat ik verschillende bronnen heb waar deze info vandaan kan komen en dus ook verschillende methods. Ik doe wat sanity checks op de data die voor alle bronnen nodig is voordat ik het zaakje in een track-object opsla. Klinkt vast vaag maar gezien mijn programmastructuur was het de meest cleane oplossing.

[Janoz]

NMe schreef op maandag 20 september 2010 @ 18:37:
Omdat ik verschillende bronnen heb waar deze info vandaan kan komen en dus ook verschillende methods. Ik doe wat sanity checks op de data die voor alle bronnen nodig is voordat ik het zaakje in een track-object opsla. Klinkt vast vaag maar gezien mijn programmastructuur was het de meest cleane oplossing.

Ik zie nog niet waarom dit een verdediging is voor het gebruik van een Map. Om eerlijk te zijn heb ik een vermoeden dat het eerder een nog ietsje blijven hangen 'For a php-programmer, everything is an Array'-mindset is. Wanneer het binnenkomende daadwerkelijk compleet variabel is (en dan bedoel ik in de hele keten tot aan het tonen op het scherm) dan is de aanpak te verdedigen. In alle andere gevallen is het efficienter en veiliger om gewoon een pojo te maken.

[Creepy]

Om eerlijk te zijn heb ik een vermoeden dat het eerder een nog ietsje blijven hangen 'For a php-programmer, everything is an Array'-mindset is.

En daar komt waarschijnlijk ook het idee vandaan dat de interne representatie van de Map een recht-toe-recht-aan array moet zijn, wat het niet is. De fout zit hem in elk geval niet in de .table, die volgorde is afhankelijk van de o.a. capacity van de Map, en die is standaard groter dan 4. Dus een paar null's aan het begin, eind of tussenin klopt. De Map wordt zeer waarschijnlijk verkeerd gevuld, of er is iets totaal anders aan de hand. De vraag blijft dus staan:

Soultaker schreef op maandag 20 september 2010 @ 12:09:
[...]

Is je laptop al geboot? Wat is het resultaat? Vertel NMe, we willen het weten, desnoods betalen we bij!

Nee, ik betaal niet bij

[ Voor 5% gewijzigd door Creepy op 20-09-2010 21:10 ]

[pedorus]

NMe schreef op maandag 20 september 2010 @ 18:37:
Overigens kan ik track zelf niet inspecten in Eclipse? Het enige dat ik dan te zien krijg is een of andere vage string representation van het object, zonder verdere info over de inhoud.

Gek, misschien ergens een oude versie. Ik kan er gewoon op klikken in 'Variables'.

We zijn als Android 2.0-project begonnen en hebben laterna het zaakje aangepast zodat het op 1.6 zou kunnen draaien. Is het mogelijk dat daarbij iets mis gaat waardoor de debugger in de war raakt? If not, dan weet ik het ook niet verder.

Waarschijnlijk heb je vervolgens onder Window->Android [...] Manager geen nieuwe virtual device aangemaakt en gestart voor je nieuwe target-api en ben je nu nog steeds aan het debuggen met 2.x.

Creepy schreef op maandag 20 september 2010 @ 21:08:
Nee, ik betaal niet bij

offtopic:
Idd, NMe is geen Bert Visscher. Hoewel, ik ben wel bereid de inleg te verdubbelen..

[Enfer]

pedorus schreef op maandag 20 september 2010 @ 23:06:
[...]
Waarschijnlijk heb je vervolgens onder Window->Andriod [...] Manager geen nieuwe virtual device aangemaakt en gestart voor je nieuwe target-api en ben je nu nog steeds aan het debuggen met 2.x.

offtopic:
Het is geen Andriod, maar Android..

Een eerlijke typo gaan corrigeren is niet nodig

[ Voor 7% gewijzigd door RobIII op 21-09-2010 13:36 ]

[Remus]

Belangrijke vraag: op welke manier (code) constateer je in je productie code dat niet alles er in zit?

[YopY]

Remus schreef op dinsdag 21 september 2010 @ 13:01:
Belangrijke vraag: op welke manier (code) constateer je in je productie code dat niet alles er in zit?

Acceptatie- of integratietests, maar wat heeft dat met dit topic te maken?

[Janoz]

Voornamelijk om uit NMe te krijgen of hij zijn missende elementen enkel baseert op deze debugsessie, of ook op andere manieren vastgesteld heeft dat de hashmap maar 2 elementen bevat,

[Remus]

YopY schreef op dinsdag 21 september 2010 @ 15:22:
[...]


Acceptatie- of integratietests, maar wat heeft dat met dit topic te maken?

Ik bedoel de exacte code waarmee hij constateert dat het fout gaat in productie, niet zijn view op de interne variabelen en fields die de debugger toont. Die interne view is erg afhankelijk van de implementatie en is niet altijd even helder.

Geschikte manieren zijn bijvoorbeeld

Java:

for (String key : justAMap.keySet()) {
  System.out.printf("Key: %s, value %s\n", key, justAMap.get(key));
}

of

Java:

for (Map.Entry<String, String> entry : justAMap.entrySet() {
  System.out.printf("Key: %s, value %s\n", entry.getKey(), entry.getValue());
}

[ Voor 38% gewijzigd door Remus op 21-09-2010 16:41 ]

[voodooless]

Is het niet toevallig zo dat er dubbele hashes worden gegenereerd, en dus de hashes van de keys meerdere values bevatten?

[Remus]

Voor de gegeven waardes zal er echt geen hash collission optreden.

[Woy]

Remus schreef op woensdag 22 september 2010 @ 12:22:
Voor de gegeven waardes zal er echt geen hash collission optreden.

Je hoeft overigens geen hash collission te krijgen, om er voor te zorgen dat een hash op dezelfde locatie komt als een andere hash. Zolang de Equals maar false oplevert, hoeft het geen probleem te zijn als er een hash collision is.

[NMe]

Voor de mensen die zo nieuwsgierig waren: de HashMap bevatte inderdaad dus gewoon alle waardes. Moet ik alleen nog zien te debuggen waarom ik die symptomen had, want juist de twee waardes waarvan ik dacht dat ze verdwenen waren uit de HashMap worden ook niet overgenomen in mijn GolfTrack-object. Maar goed, daar ga ik wel uitkomen, hoop ik, nu ik me niet meer blindstaar op een stukje code dat dus altijd heeft gefunctioneerd as intended.