Dictionary(Hur identifiera objekt i en sådan om de inte finns däri?)[/Mod]

Hejsan behöver lite hjälp med att loopa igenom en dictionary. Vill få ut IButton men lyckas inte :/ Skulle uppskatta med lite fingervisning. GetAllButtons returnerar en Dictionary med samma värden som den som jag har döpt till map. Skulle vilja kunna få ut både stringen och IButton så att ifall en av knapparna inte finns. Så ska jag kunna identifiera den genom stringen.

Nu var Java länge sen och jag är trött, men skulle du inte kunna loopa över strängarna och sen göra get på din button, och sen kolla om det du får är null - då finns den inte?

Inte säker på att jag förstår problemet, det är inte alldeles självklart givet texten.

Om jag förstått det rätt vill du alltså ta reda på om en knapp inte finns och då få fram dess nyckel, är det så?

Ditt kodexempel förvirrar ju aningen med, men vad händer oom du skulle typa om din dictionary till något mer användbart, typ en HashTable? Då skulle du ju kunna få tag på en hel del andra goodies och då avgöra om entries finns eller ej?

Du kommer bli tvungen att ändra metoden så den ger ifrån sig ett Map.Entry, men gör du det ska du i teorin kunna få tag på ett nycke-värdepar, precis som du ville ha det?

Edit: Fan, kanske inte funkar ändå när jag tänker efter. Paketera om din Dictionary till något användbart, typ en HashTable, för Dictionary i sig är ju rätt oanvändbart, alternativt något annat som implementerar Map-interfacet.

Ska prova nu

Tack för hjälpen allihop. Löste det med att casta om allt till Hashmap. Dictionary funkar tydligen mycket annorlunda i java än vad den gör i .NET. Tack för kunskapen!

Även om du har löst problemet kan det vara bra att förtydliga att Dictionary och Hashtable är föråldrade delar av Java v1.0 från mitten av 90-talet, som inte rekommenderas att man använder längre. De ersattes redan i v1.2 (1998) med Map och HashMap (när trådsäkerhet inte är ett krav) eller ConcurrentHashMap (när trådsäkerhet behövs).

Nej.

Däremot implementerar HashTable Map-interfacet sedan v1.2, dessutom är en HashTable synchronized out-of-the-box, behövs inte trådsäkerhet rekommenderas istället en HashMap, behöver man däremot en trådsäker HashMap rekommenderas däremot ConcurrentHashMap, allt enligt java-apiet för HashTable.

Uhm, jo definitivt!

Ja, inte i strid med det jag sa.

Ja, inte i strid med det jag sa.

Ett av delmålen med Java Collections Framework i v1.2 var att lösa problemet med att det bara fanns synchronized-alternativ. I de allra flesta fall fanns det inte behov av detta och därmed blev det en ständig performance-kostnad man ville råda bot på.

Hashtable (och några till) levde kvar parallellt som det synkroniserade alternativet i de fall de behövdes, för att till sist bli helt överflödiga när v1.5 kom (2005) med hela det nya java.util.concurrent-paketet, som innehålller bland annat ConcurrentHashMap. ConcurrentHashMap implementerar en mycket smartare låsningsstrategi (lock striping) som gör den extremt mycket effektivare än Hashtable. Upphovsmännen (kommer inte ihåg längre vilka, men skulle misstänka åtminstone Doug Lea och Brian Goetz) själva verkar riktigt nöjda med sitt resultat och har påtalat många gånger hur nära den ligger HashMap i prestanda.

Men detta är så långt tillbaka att det enda man egentligen behöver veta nu, är att dessa gamla API-delar (dvs bland annat Dictionary och Hashtable) endast finns kvar för bakåtkompatibilitet och inte är tänkta att användas längre. Resten är bara av historiskt intresse.

Precis. Du, jag och Core API:t är helt överrens. Vad var problemet här?

Problemet är att i java-apiet finner jag inga belägg för ditt påstående om att HashTable inte är tänkt att användas längre. Hade det varit så borde ju klassen vara markerad deprecated, samt att en notis nånstans i apiet borde det ju stå nåt om "usage strongly discouraged"?

Var står det att denna manick endast finns kvar av bakåtkompatibilitets-skäl?

Då får jag be om ursäkt för att jag uttrycker mig dåligt. Det enda jag menar är att Core API:et rekommenderar de nyare alternativen. De är mycket riktigt inte deprecated.

Återigen kanske dåligt ordval. Jag menar endast att de inte kan ta bort dem för de inte vill riskera bryta befintlig kod. Har aldrig sett dem ange dessa skäl i Core API:t, nej. Däremot uttryckt av skribenter involverade i utvecklingen av Javas Core API genom åren i många andra externa publikationer.

Tycker vi hamnar lite väl långt från poängen nu.

Håller med, därför föreslår jag att vi släpper detta nu, du har dessutom argumenterat på ett vettigt sätt och det finns från min sida inte några frågetecken kvar.