Archief - java: probleem met if

math · 8 apr 2009

yo,
Ik heb een methode geschreven die een gebruikersnaam krijgt en dan een wachtwoord terug stuurt. Het probleem is dat het altijd een lege String terug geeft.

Ik heb de debug eens laten lopen en op een bepaald moment krijg ik bij de if dit: "test" == "test", maar ww blijft leeg.

public String geefPersoneelsWachtwoord(String loginNaam){
String ww="";

for(int i=0; i< personeelslijst.size();i++){

String naam=personeelslijst.get(i).getGebruikersNaam();

if(loginNaam == naam){
JOptionPane.showMessageDialog(null,"jjjjjjjjjjjjjjjjjjjjjj");
ww = "testww"//personeelslijst.get(i).getWachtwoord();
return ww;
}
}
return ww;
}

MacK · 8 apr 2009

loginNaam.equals(naam) ipv loginNaam == naam

Nu vergelijk je enkel de referenties naar de objecten (die in dit geval verschillend zullen zijn), terwijl je eigenlijk de inhoud moet vergelijken. De String-klasse overschrijft de default functionaliteit van equals (namelijk referenties vergelijken) door een karakter-per-karakter vergelijking, zoals het hoort.

Jerre Muesli · 9 apr 2009

Voor primitieve datatypes als int, short, byte, double, boolean, .... etc moet je idd met == werken.
Voor objecten als String, Boolean, Integer, .. (let op de hoofdletter) werk je met de functie equals() die zoals MacK zei de inhoud van het object vergelijkt.

Krueger · 9 apr 2009

Waarom is er eigenlijk in java een onderscheid tussen Boolean en boolean. Waarom hebben ze niet standaard gekozen voor het basistype?

Squealer · 9 apr 2009

boolean is een primitive datatype
Boolean is de wrapper klasse voor een boolean primitive.

Net zoals Integer dat is voor int bv....

Waarom bestaan die wrapper klassen? Omdat je zo bv primitives kan gaan doorgeven aan functies die eigenlijk objecten verwachten... En omdat er in de wrapper klassen ruimte is om extra functionaliteit te steken, in een primitive uiteraard niet...

Cycloon · 9 apr 2009

Krueger zei:
Waarom hebben ze niet standaard gekozen voor het basistype?

De correcte vraag zou zijn: Waarom hebben ze niet standaard gekozen voor het object type?

Krueger · 9 apr 2009

Cycloon zei:
De correcte vraag zou zijn: Waarom hebben ze niet standaard gekozen voor het object type?

Erm, juist ja

forloRn_ · 9 apr 2009

De vraag is: waarom heeft een OO-taal als Java primitives?

James Gosling zei:
Totally an efficiency thing. There are all kinds of people who have built systems where ints and that are all objects. There are a variety of ways to do that, and all of them have some pretty serious problems. Some of them are just slow, because they allocate memory for everything. Some of them try to do objects where sometimes they are objects, sometimes they are not (which is what the standard LISP system did), and then things get really weird. It kind of works, but it's strange.

Het probleem is inderdaad dat je die primitives niet op een generieke manier kunt gebruiken, waar je dat bij objects wel kunt, aangezien objects allemaal overerven van Object. Je kunt primitives dus bijvoorbeeld ook niet in een collection stoppen, aangezien een collection enkel Objects kan bevatten. De wrapper types bieden daar een oplossing.

Er zijn mensen die vinden dat het ondersteunen van primitives in Java een design flaw is en ze zullen waarschijnlijk wel gelijk hebben, maar door autoboxing/unboxing heb je er in de praktijk weinig of geen last van.

Squealer · 9 apr 2009

Cycloon zei:
De correcte vraag zou zijn: Waarom hebben ze niet standaard gekozen voor het object type?

Omdat objecten veel meer geheugen innemen?

Krueger · 9 apr 2009

-P|b-SqUeaLeR zei:
Omdat objecten veel meer geheugen innemen?

Mjah, in c# is dat zo, en ik denk toch niet dat het groot geheugengebruik een echt minpunt is van die taal.

Cycloon · 9 apr 2009

-P|b-SqUeaLeR zei:
Omdat objecten veel meer geheugen innemen?

Dat is totale nonsense natuurlijk, want het hele object gebeuren vraagt meer geheugen. Laten we terug gaan naar proceduraal programmeren dan.

Java presenteert zich als dé OO-taal, zelf al moeten ze zich daarvoor in alle mogelijke bochten wringen, waarom ze dan een uitzondering maken voor primitieve types heb ik altijd wel raar gevonden.

Uiteindelijk kan je de primitieve types in veel situaties toch niet gebruiken (denk maar aan alle collections). Ik heb er eigenlijk nooit een echte reden voor gezocht maar ik ben wel benieuwd. Dat ze meer geheugen zouden vragen lijkt me een redelijk zwak excuus.

Squealer · 10 apr 2009

Het zal wel 1 van de redenen zijn. Heb me der eigenlijk nog nooit vragen bij gesteld....
Maar bij collections kan je bv wel gewoon een variabele van type int in een map van Integers steken. Dat wordt vanzelf omgezet.

En je geeft me dus eigenlijk wel gelijk als ik zeg dat objecten meer geheugen innemen? Je zegt gewoon dat dat "niet relevant genoeg is", of versta ik u verkeerd?
In bepaalde gevallen kan het wel degelijk interessant zijn om geheugen te besparen...
Een boolean bv neemt 1 byte in... Een object header alleen al neemt 8 bytes in.... En de grootte van elk object is altijd een veelvoud van 8 bytes. Een Boolean wrapper object is dus 16 bytes groot. Uw 4 bytes voor de reference naar dat object ook niet vergeten...
+ Wanneer dat geheugen vrijgegeven wordt, wordt bepaald door de garbage collector ("ooit eens" tenzij forced)... Bij primitives niet, aangezien die waarden rechtstreeks op de stack staan.

In welke programmeertaal heb je dan géén primitieven?

Nog andere reden waar ik aan denk:
- objecten aanmaken is relatief duur... Zeker ivg met een primitive toewijzen.
- in java is alles by reference. Mij lijkt het wel handig om simpele primitives bij de hand te hebben die zich by value gedragen...
- er is geen operator overloading in java.
Dat wordt dus:
Integer a,b,c,d,...
a=b.add(c).times(d).divideBy(a);
Tenzij ze String's uitzondering overzetten naar de wrapper classes...

Cycloon · 10 apr 2009

-P|b-SqUeaLeR zei:
En je geeft me dus eigenlijk wel gelijk als ik zeg dat objecten meer geheugen innemen? Je zegt gewoon dat dat "niet relevant genoeg is", of versta ik u verkeerd?

Je verstaat me goed

-P|b-SqUeaLeR zei:
- objecten aanmaken is relatief duur... Zeker ivg met een primitive toewijzen.
- in java is alles by reference. Mij lijkt het wel handig om simpele primitives bij de hand te hebben die zich by value gedragen...
- er is geen operator overloading in java.

Je kan perfect Integer/Double/Long/... variabelen optellen/aftrekken/.. met de +-/* tekens omdat java automatisch gaat unboxen. Voor de rest lijkt het enkel neer te komen op het feit dat objecten meer resources gebruiken. Het kan best zijn dat dat de enige reden is natuurlijk.

Squealer · 11 apr 2009

Cycloon zei:
Je kan perfect Integer/Double/Long/... variabelen optellen/aftrekken/.. met de +-/* tekens omdat java automatisch gaat unboxen.

Ik wist dat je dat ging zeggen.

Bedenk dat we het hier hebben over een situatie waar er geen primitives meer zijn. Bijgevolg bestaat er ook helemaal geen boxing of unboxing meer van of naar die primitives

Parnakra · 11 apr 2009

Als je dan toch de moeite zou doen om alle primitives te verwijderen, kan je evengoed operator overloading implementeren.

De reden waarom ze het niet gedaan hebben, is op z'n best twijfelachtig te noemen. Zeker als je ziet dat ze voor String een uitzondering gemaakt hebben.

Zoals ik een tijdje geleden las, (geparafraseerd) geef de programmeur alle mogelijkheden om slechte code te schrijven, dan weet je bij wie de schuld ligt als het gebeurt.

/edit:

Good programmers should be given absolute power. If they create a mess then give them the blame. Don't make the better ones suffer because of that possibility.

forloRn_ · 11 apr 2009

Och operator overloading, heeft iemand dat eigenlijk al gemist in Java? Ik in elk geval niet. Da's misschien handig als je een math library schrijft of een 3D engine maar voor de doorsnee applicatie heeft dat toch maar weinig nut. Dat gezegd zijnde, mogen ze van mij wel [] overloaden voor een List of een Map.

Messias. · 11 apr 2009

forloRn_ zei:
Och operator overloading, heeft iemand dat eigenlijk al gemist in Java? Ik in elk geval niet. Da's misschien handig als je een math library schrijft of een 3D engine maar voor de doorsnee applicatie heeft dat toch maar weinig nut. Dat gezegd zijnde, mogen ze van mij wel [] overloaden voor een List of een Map.

Heil Scala.

(Hoewel dat technisch gezien niet echt operator overloading is, omdat Scala in z'n geheel de notie van operators niet kent.)

En wat betreft dat laatste, Scala can do that. Scala laat u zelfs toe om shorthand te specificeren bij je eigen datastructuren met behulp van function objects.

Cycloon · 11 apr 2009

-P|b-SqUeaLeR zei:
Ik wist dat je dat ging zeggen.
Bedenk dat we het hier hebben over een situatie waar er geen primitives meer zijn. Bijgevolg bestaat er ook helemaal geen boxing of unboxing meer van of naar die primitives

Wat er achter de schermen gebeurt maakt niet uit natuurlijk. Het is niet omdat de programmeur geen primitieve types mag gebruiken dat het plots ook verboden is voor de taal, anders kan je natuurlijk nooit nog een Integer/Double/Long klasse maken.

killgore · 12 apr 2009

Cycloon zei:
Dat is totale nonsense natuurlijk, want het hele object gebeuren vraagt meer geheugen. Laten we terug gaan naar proceduraal programmeren dan.

Waarom zou OO inherent meer geheugen vereisen dan niet-OO :wtf:

?

Cycloon · 12 apr 2009

killgore zei:
Waarom zou OO inherent meer geheugen vereisen dan niet-OO ?

Wil je daar nu serieus een antwoord op? :wtf:

Of wil je ook dat ik ga uitleggen waarom de meeste kippen kakelen en schapen dat niet doen?

Archief - java: probleem met if

math

Legacy Member

MacK

Legacy Member

Jerre Muesli

Legacy Member

Krueger

Legacy Member

Squealer

Legacy Member

Cycloon

Legacy Member

Krueger

Legacy Member

forloRn_

Legacy Member

Squealer

Legacy Member

Krueger

Legacy Member

Cycloon

Legacy Member

Squealer

Legacy Member

Cycloon

Legacy Member

Squealer

Legacy Member

Parnakra

Legacy Member

forloRn_

Legacy Member

Messias.

Legacy Member

Cycloon

Legacy Member

killgore

Legacy Member

Cycloon

Legacy Member