Re: java.security.Permission
A este si treba pozriet Javadoc k samotnemu objektu java.lang.Object. Tam sa pise o metode hashCode(), ze musi byt implementovana tak aby dva objekty, ktore su equals() musia mat rovnaky hshCode().
Re: java.security.Permission
Dobre, ale potom nechapu proc neni soucasti
rodicovske tridy Permission zakladni implementace
zalozena treba na metode getName (), tak jako je toho
docileno v BasicPermission tride...
Ja se chtel jenom zeptat, jestli v tom neni nejakej
figl, nebo jestli je to jenom nedomyslenost...
- Original Message -
From: Jiří Mareš [EMAIL PROTECTED]
To: Java konference@java.cz
Sent: Thursday, July 27, 2006 7:31 AM
Subject: Re: java.security.Permission
Ja bych teda pouzil javadoc, kde jsem se vysvetleni dobral naprosto v
pohode ...
The required hashCode behavior for Permission Objects is the following:
* Whenever it is invoked on the same Permission object more than once
during an execution of a Java application, the
hashCode method must consistently return the same integer. This integer
need not remain consistent from one execution of
an application to another execution of the same application.
* If two Permission objects are equal according to the equals method,
then calling the hashCode method on each of
the two Permission objects must produce the same integer result.
Nevim proc jsou tyto pozadavky, ale jsou. Standardni implementace hashcode
vychazi z toho, jak je objekt alokovan, tj.
kde v heapu je a proto ma kazda instance jiny hash, zda ho pozaduji mit
stejny i napric ruznymi instancemi JVM. Proto si
jej musite implementovat sam ...
Priste se mrknete do javadoc a pak se ptejte :-)
Kamzik-II napsal(a):
Hm asi mate v tomhle pravdu :)
Jak se vyznate s Permission? Nemohl byste mi
poradit nejakej fine tutorial, kde je popsana tvorba
vlastni implementace? BtW: Diky
- Original Message - From: Lumír Návrat
[EMAIL PROTECTED]
To: Java konference@java.cz
Sent: Wednesday, July 26, 2006 10:16 PM
Subject: Re: java.security.Permission
No klasicky priklad se uvadi u entitnich objektu, kdy si predstav, ze
mas vytisk knihy, ten je identifikovan jednak cislem titulu a dale
prirustkovym cislem v ramci daneho titulu.
Pokud by jsi pouzil defaultni implementaci, tak by se to porovnavalo
pouze na rovnost instanci.
To znamena, ze pokud by jsi udelal:
Vytisk v1 = new Vytisk(123455,1/2006);
Vytisk v2 = new Vytisk(123455,2/2006);
v1.equals(v2); // vysledek je false, jelikoz: v1 = this, v2 = object
a telo metody equals obsahuje return this == object, coz je porovnavani
adres instacni.
Proto je nutne provest nasledujici reimplementaci:
public boolean equals(Object object) {
if (object == null) {
return false;
}
if (object instanceof Vytisk) {
Vytisk pomV = (Vytisk)object)
return this.id == pomV prirustek.equals(pomV.prirustek);
}
return false;
}
Samotna implementace hashcode sice neni zivotne nutna, ale je s ruznych
duvodu, ktere si jiz nepamatuji doporucena.
Lumi(r)
Kamzik-II wrote:
No tak to mi potom neni vubec jasne, proc
bych to mel reimplementovat
- Original Message - From: Lumír Návrat
[EMAIL PROTECTED]
To: Java konference@java.cz
Sent: Wednesday, July 26, 2006 9:14 PM
Subject: Re: java.security.Permission
Nazdar,
strucne co si pamatuji z knizky 57 rad efektivne v JAVe (nebo
obdobne) od Blochua, tak to vychazi ze zakladu jedinecnosti objektu a
zpusobu jeho porovnavani ve virtualnim stroji. Tyto metody se dedi
primo z tridy Object a maji je implementovane vsechny tridy. pravidlo
je takove, ze equals zajistuje shodu na urovni aplikace a hashcode na
urovni VM = v ruznych instancich VM hashcode myslim muze byt ruzny,
zatimco equals je vzdy stejne, ale nejsem si tim ted jisty:(
Plati vsak, pokud se reimplementuje equals, tak se musi
reimplementovat i hashcode
Lumi(r)
Kamzik-II wrote:
Dobry vecer,
prokousavam se bezpecnosti v Jave
a narazil jsem na tridu Permission.
Rad bych si napsal svou vlastni implementaci,
ale trochu me desi nektere metody, oznacene, jako
abstraktni, napriklad mi neni jasne, proc by mel
Permission objekt povinne reimplementovat metodu hashcode a equals,
to equals bych mozna jeste pochopil,
ale hashcode mi prijde jako uplna blbost.
--
Jiří Mareš (mailto:[EMAIL PROTECTED])
ČSAD SVT Praha, s.r.o. (http://www.svt.cz)
Czech Republic
Re: java.security.Permission
Kamzik-II wrote: Ale paklize by tohle vzdy platilo, pak by byla uplna blbost predefinovat metodu equals, protoze by v ni stacilo porovnavat hascode, kdezto v rodicovske implementaci se porovnavaji pouze instance Ta implikace plati pouze jednim smerem! Dva objekty muzou mit stejny hashCode, ale dle metody equals se nerovnaji. Hashcode nemusi byt perfektni ;-)
Re: java.security.Permission
Ja bych doporucoval precist si nejake zaklady programovani, kde se dozvite takovedle zalezitosti a pak hned navazat zakladama programovani v jave :-)) Kamzik-II napsal(a): Ale paklize by tohle vzdy platilo, pak by byla uplna blbost predefinovat metodu equals, protoze by v ni stacilo porovnavat hascode, kdezto v rodicovske implementaci se porovnavaji pouze instance. - Original Message - *From:* Richard Malaschitz mailto:[EMAIL PROTECTED] *To:* Java mailto:konference@java.cz *Sent:* Thursday, July 27, 2006 10:58 AM *Subject:* Re: java.security.Permission A este si treba pozriet Javadoc k samotnemu objektu java.lang.Object. Tam sa pise o metode hashCode(), ze musi byt implementovana tak aby dva objekty, ktore su equals() musia mat rovnaky hshCode(). -- Jiří Mareš (mailto:[EMAIL PROTECTED]) ČSAD SVT Praha, s.r.o. (http://www.svt.cz) Czech Republic
Re: java.security.Permission
Kamzik-II wrote: Ale paklize by tohle vzdy platilo, pak by byla uplna blbost predefinovat metodu equals, protoze by v ni stacilo porovnavat hascode, kdezto v rodicovske implementaci se porovnavaji pouze instance. Mozna byste si o tom mel neco precist, dobry clanek je treba http://www.javaworld.com/javaworld/jw-01-1999/jw-01-object-p2.html hashCode() vraci integer, takze moznych ruznych ( z hlediska equals()) objektu muze byt vice, nez je integer hodnot, napriklad ruznych objektu typu Long. Proto equals() nemuze jenom porovnavat hashCode() hodnoty. Makub -- ~~ Supercomputing Center Brno Martin Kuba Institute of Computer Scienceemail: [EMAIL PROTECTED] Masaryk University http://www.ics.muni.cz/~makub/ Botanicka 68a, 60200 Brno, CZ mobil: +420-603-533775 -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Zamedzenie viacnasobnemu vykonaniu metody
Co takhle to resit jako constraint/trigger v databazi? Jde prece o to,
aby data sedele, tj. abych mel bud nakup a nebo zaznam o stornu. Pokud
mate spravne integritni omezeni v databazi, nemela by se vam takovato
vec stat.
Tom
jeeff napsal(a):
Ahojte,
vo web rozhrani riesim ako zamedzit viacnasobnemu zavolaniu nejakej
metody.
Priklad:
majme metodu pre stornovanie nakupu pri ktorom sa vracia suma za nakup
na ucet nakupujuceho. Je to spravene ako staticka metoda:
public class NakupyDB
{
public static boolean stornoNakup(NakupBean nakup)
{
//najskor skontrolujme ci uz nahodou nie je stornovany
if (nakupBean.isStornovany()) return false;
//vratime sumu na ucet
//nastavime ze je to stornovane
nakupBean.setStornovany(true);
//uloz nakup do DB
return true;
}
}
Tato metoda je volana z JSP stranky po kliknuti na prislusnu linku.
Chcem zamedzit tomu, ze nakupujuci 2x klikne na linku, pripadne si
otvori stranku v 2 oknach a naraz klikne 2x. V tom pripade by sa mu
suma za nakup mohla vratila viac krat - ak by prvy thread presiel za
test if (nakupBean.isStornovany()) return(false); a potom sa web
server prepol do druheho threadu a ten by sa tiez dostal za tento test.
Ako najjednoduchsie riesenie sa mi zda spravit celu metodu ako
synchronized. Nie je z nej volany ziadny iny synchronized blok, takze
by teoreticky nemalo dojst k deadlocku. Neviem ci by sa ale zamok
spravne odomkol, keby doslo k nejakemu divnemu stavu, napr. Out Of
Memmory alebo nieco podobne.
Padol tu aj navrh o napisani filtra, ktory by neumoznil viac krat
sucasne (pre daneho navstevnika) zavolat rovnake URL.
Akym sposobom taketo situacie riesite vy?
Re: Zamedzenie viacnasobnemu vykonaniu metody
Ja to resil pres ulozen objektu nakupniho kosiku do session uzivatele,
plus synchronized metoda aby ji nemohl volat dokud nedobehla. Pokud ma
dve okna prohlizece, jsou to dve session, takze problem nevznikne --
nakupni kosiky ma taky dva, a stornuje kazdy zvlast. A session listener
v metode sessionDestroyed() kosik automaticky vysype, pokud v nem tedy
neco je. Pokud padne cely server kvuli OutOfMemoryError, tak to pravd.
bude vetsi problem a bude se to muset resit rucne. Funguje to zatim
celkem dobre :-))
Mirek
Tomas Hubalek napsal(a):
Co takhle to resit jako constraint/trigger v databazi? Jde prece o to,
aby data sedele, tj. abych mel bud nakup a nebo zaznam o stornu. Pokud
mate spravne integritni omezeni v databazi, nemela by se vam takovato
vec stat.
Tom
jeeff napsal(a):
Ahojte,
vo web rozhrani riesim ako zamedzit viacnasobnemu zavolaniu nejakej
metody.
Priklad:
majme metodu pre stornovanie nakupu pri ktorom sa vracia suma za nakup
na ucet nakupujuceho. Je to spravene ako staticka metoda:
public class NakupyDB
{
public static boolean stornoNakup(NakupBean nakup)
{
//najskor skontrolujme ci uz nahodou nie je stornovany
if (nakupBean.isStornovany()) return false;
//vratime sumu na ucet
//nastavime ze je to stornovane
nakupBean.setStornovany(true);
//uloz nakup do DB
return true;
}
}
Tato metoda je volana z JSP stranky po kliknuti na prislusnu linku.
Chcem zamedzit tomu, ze nakupujuci 2x klikne na linku, pripadne si
otvori stranku v 2 oknach a naraz klikne 2x. V tom pripade by sa mu
suma za nakup mohla vratila viac krat - ak by prvy thread presiel za
test if (nakupBean.isStornovany()) return(false); a potom sa web
server prepol do druheho threadu a ten by sa tiez dostal za tento test.
Ako najjednoduchsie riesenie sa mi zda spravit celu metodu ako
synchronized. Nie je z nej volany ziadny iny synchronized blok, takze
by teoreticky nemalo dojst k deadlocku. Neviem ci by sa ale zamok
spravne odomkol, keby doslo k nejakemu divnemu stavu, napr. Out Of
Memmory alebo nieco podobne.
Padol tu aj navrh o napisani filtra, ktory by neumoznil viac krat
sucasne (pre daneho navstevnika) zavolat rovnake URL.
Akym sposobom taketo situacie riesite vy?
Re: Zamedzenie viacnasobnemu vykonaniu metody
Podle me tu nejde ale o nakupni kosik, ale o to, aby z uctu neodesly
penize dvakrat. A to si opravdu myslim ze je integritni omezeni a ne
zalezitost business logiky. Navic napsat trigger, ktery se zavola
vzdycky pri stornu objednavky a podiva se, jestli je na storno narok je
celkem jednoducha vec.
Na urovni business logiky/web ui pak uz jenom jednoduse odchytite
patricnou exception a tu pak ukazete uzivateli (samozrejme bez
stacktrace ;-))...
Tom
Mirek Stohr napsal(a):
Ja to resil pres ulozen objektu nakupniho kosiku do session uzivatele,
plus synchronized metoda aby ji nemohl volat dokud nedobehla. Pokud ma
dve okna prohlizece, jsou to dve session, takze problem nevznikne --
nakupni kosiky ma taky dva, a stornuje kazdy zvlast. A session
listener v metode sessionDestroyed() kosik automaticky vysype, pokud
v nem tedy neco je. Pokud padne cely server kvuli OutOfMemoryError,
tak to pravd. bude vetsi problem a bude se to muset resit rucne.
Funguje to zatim celkem dobre :-))
Mirek
Tomas Hubalek napsal(a):
Co takhle to resit jako constraint/trigger v databazi? Jde prece o
to, aby data sedele, tj. abych mel bud nakup a nebo zaznam o stornu.
Pokud mate spravne integritni omezeni v databazi, nemela by se vam
takovato vec stat.
Tom
jeeff napsal(a):
Ahojte,
vo web rozhrani riesim ako zamedzit viacnasobnemu zavolaniu nejakej
metody.
Priklad:
majme metodu pre stornovanie nakupu pri ktorom sa vracia suma za
nakup na ucet nakupujuceho. Je to spravene ako staticka metoda:
public class NakupyDB
{
public static boolean stornoNakup(NakupBean nakup)
{
//najskor skontrolujme ci uz nahodou nie je stornovany
if (nakupBean.isStornovany()) return false;
//vratime sumu na ucet
//nastavime ze je to stornovane
nakupBean.setStornovany(true);
//uloz nakup do DB
return true;
}
}
Tato metoda je volana z JSP stranky po kliknuti na prislusnu linku.
Chcem zamedzit tomu, ze nakupujuci 2x klikne na linku, pripadne si
otvori stranku v 2 oknach a naraz klikne 2x. V tom pripade by sa mu
suma za nakup mohla vratila viac krat - ak by prvy thread presiel za
test if (nakupBean.isStornovany()) return(false); a potom sa web
server prepol do druheho threadu a ten by sa tiez dostal za tento test.
Ako najjednoduchsie riesenie sa mi zda spravit celu metodu ako
synchronized. Nie je z nej volany ziadny iny synchronized blok,
takze by teoreticky nemalo dojst k deadlocku. Neviem ci by sa ale
zamok spravne odomkol, keby doslo k nejakemu divnemu stavu, napr.
Out Of Memmory alebo nieco podobne.
Padol tu aj navrh o napisani filtra, ktory by neumoznil viac krat
sucasne (pre daneho navstevnika) zavolat rovnake URL.
Akym sposobom taketo situacie riesite vy?
Re: Zamedzenie viacnasobnemu vykonaniu metody
Ja myslim, ze tady je tezke neco radit
Proc nemate nakup jako radek v db a u nej priznak, ze je zruseny ... pokud
tento priznak neni nahozeny, pak vracite,
jinak reknete, ze je objednavka jiz zrusena :-)))
jeeff napsal(a):
Ahojte,
vo web rozhrani riesim ako zamedzit viacnasobnemu zavolaniu nejakej metody.
Priklad:
majme metodu pre stornovanie nakupu pri ktorom sa vracia suma za nakup
na ucet nakupujuceho. Je to spravene ako staticka metoda:
public class NakupyDB
{
public static boolean stornoNakup(NakupBean nakup)
{
//najskor skontrolujme ci uz nahodou nie je stornovany
if (nakupBean.isStornovany()) return false;
//vratime sumu na ucet
//nastavime ze je to stornovane
nakupBean.setStornovany(true);
//uloz nakup do DB
return true;
}
}
Tato metoda je volana z JSP stranky po kliknuti na prislusnu linku.
Chcem zamedzit tomu, ze nakupujuci 2x klikne na linku, pripadne si
otvori stranku v 2 oknach a naraz klikne 2x. V tom pripade by sa mu suma
za nakup mohla vratila viac krat - ak by prvy thread presiel za test if
(nakupBean.isStornovany()) return(false); a potom sa web server prepol
do druheho threadu a ten by sa tiez dostal za tento test.
Ako najjednoduchsie riesenie sa mi zda spravit celu metodu ako
synchronized. Nie je z nej volany ziadny iny synchronized blok, takze by
teoreticky nemalo dojst k deadlocku. Neviem ci by sa ale zamok spravne
odomkol, keby doslo k nejakemu divnemu stavu, napr. Out Of Memmory alebo
nieco podobne.
Padol tu aj navrh o napisani filtra, ktory by neumoznil viac krat
sucasne (pre daneho navstevnika) zavolat rovnake URL.
Akym sposobom taketo situacie riesite vy?
--
Jiří Mareš (mailto:[EMAIL PROTECTED])
ČSAD SVT Praha, s.r.o. (http://www.svt.cz)
Czech Republic
Re: equals a hashCode (WAS: java.security.Permission)
O boze, equals tady nekdo pekne vysvetlil na vytiscich knih, hascode vicemene taky chapu, ale neni mi jasne na co je mi dobrej ;-) - Original Message - From: Vit Novak To: 'Java' Sent: Thursday, July 27, 2006 1:07 PM Subject: equals a hashCode (WAS: java.security.Permission) Zdravim. Doporucuji precist si knizku od pana Blocha (cesky Java efektivne, anglicky Effective Java). Pan Bloch tuto problematiku rozebira pomerne podrobne a myslim, ze tohle patri k zakladnim znalostem, bez kterych dobry Java kod proste psat nebudete. Jedna se totiz o to, ze predefinovani metody equals nebo hashCode vas zavazuje k dodrzeni urcitych pravidel, bez kterych vam treba Collections budou chodit _velmi_ divne nebo vubec. Samozrejme je mozne nadefinovat hashCode a equals implementovat jen jako porovnani hashCode, to ovsem casto neni to, co chcete. Vetsinou jdete obracene nejak si urcite, kdy maji byt dve instance nejake tridy rovne a to naimplementujete. Napriklad budete mozna chtit aby dve ruzne instance tridy mujBigInt, reprezentujici cislo 37, vratily na equals true, ale reprezentace cisla 37 a cisla 56498765654987984632159789 by na equals true vratit nemela. Pak Vas ovsem hashCode zavazuje, aby equals instance vracely stejny hashCode, ale nijak Vas nenuti, aby pro dve instance, ktere equals nejsou byly hashCode ruzne. A zrovna u mujBigIntu hashCode tak, aby pro kazda dve nonequals cisla vratil ruzne hashe, proste nevymyslite. Dalsi vec je, ze kod, kde equals je implementovano jako porovnani hashi, nebude zrovna moc citelny... Toz tak, hodne stesti V. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kamzik-IISent: 27. července 2006 12:49To: JavaSubject: Re: java.security.Permission Ale paklize by tohle vzdy platilo, pak by byla uplna blbost predefinovat metodu equals, protoze by v ni stacilo porovnavat hascode, kdezto v rodicovske implementaci se porovnavaji pouze instance. - Original Message - From: Richard Malaschitz To: Java Sent: Thursday, July 27, 2006 10:58 AM Subject: Re: java.security.Permission A este si treba pozriet Javadoc k samotnemu objektu java.lang.Object. Tam sa pise o metode hashCode(), ze musi byt implementovana tak aby dva objekty, ktore su equals() musia mat rovnaky hshCode().
Re: Zamedzenie viacnasobnemu vykonaniu metody
jeeff wrote: Takze znova opakujem, storno nakupu je len priklad, moze to byt cokolvek co nechcem aby sa cez web rozhranie dalo zavolat 2x nez to zbehne cele do konca. Vobec to nemusi pracovat s databazou. Riesite taketo veci, alebo si poviete, ze taka situacia nenastane a kaslete na to? Samozrejme, pro vsechny multithreadove aplikace (a vubec nezalezi na tom zda jsou webove ci ne) plati, ze je nutne synchronizovat (ci pouzit nejakou sofistikovanejsi techniku). Pouzivani synchronized neni neco navic - je to jedna ze zakladnich veci nutna pri psani v Jave. Vsude a stale. Tim samozrejme nemyslim ze by se vsude melo cpat synchronized, chran buh - jen je nutne nad tim premyslet. -- Kamil Podlesak [EMAIL PROTECTED]
Re: equals a hashCode (WAS: java.security.Permission)
Kamzik-II wrote: O boze, equals tady nekdo pekne vysvetlil na vytiscich knih, hascode vicemene taky chapu, ale neni mi jasne na co je mi dobrej ;-) Hashcode je dobrej v okamziku, kdyz se patricny objekt uklada do hashtabulky ci mnoziny. A to s nejvetsi pravdepodobnosti bude. -- Kamil Podlesak [EMAIL PROTECTED]
Re: equals a hashCode (WAS: java.security.Permission)
Porovnavat objekty podle hashCode je hloupost. HashCode vubec nemusi byt unikatni. Tzn. muzete mit vice ruznych objektu se stejnym hashCodem. Neni zadny problem vracet konstantu jako hashCode, ale je to krajne neefektivni reseni. - Original Message - From: Kamzik-II To: Java Sent: Thursday, July 27, 2006 3:24 PM Subject: Re: equals a hashCode (WAS: java.security.Permission) O boze, equals tady nekdo pekne vysvetlil na vytiscich knih, hascode vicemene taky chapu, ale neni mi jasne na co je mi dobrej ;-) - Original Message - From: Vit Novak To: 'Java' Sent: Thursday, July 27, 2006 1:07 PM Subject: equals a hashCode (WAS: java.security.Permission) Zdravim. Doporucuji precist si knizku od pana Blocha (cesky Java efektivne, anglicky Effective Java). Pan Bloch tuto problematiku rozebira pomerne podrobne a myslim, ze tohle patri k zakladnim znalostem, bez kterych dobry Java kod proste psat nebudete. Jedna se totiz o to, ze predefinovani metody equals nebo hashCode vas zavazuje k dodrzeni urcitych pravidel, bez kterych vam treba Collections budou chodit _velmi_ divne nebo vubec. Samozrejme je mozne nadefinovat hashCode a equals implementovat jen jako porovnani hashCode, to ovsem casto neni to, co chcete. Vetsinou jdete obracene nejak si urcite, kdy maji byt dve instance nejake tridy rovne a to naimplementujete. Napriklad budete mozna chtit aby dve ruzne instance tridy mujBigInt, reprezentujici cislo 37, vratily na equals true, ale reprezentace cisla 37 a cisla 56498765654987984632159789 by na equals true vratit nemela. Pak Vas ovsem hashCode zavazuje, aby equals instance vracely stejny hashCode, ale nijak Vas nenuti, aby pro dve instance, ktere equals nejsou byly hashCode ruzne. A zrovna u mujBigIntu hashCode tak, aby pro kazda dve nonequals cisla vratil ruzne hashe, proste nevymyslite. Dalsi vec je, ze kod, kde equals je implementovano jako porovnani hashi, nebude zrovna moc citelny... Toz tak, hodne stesti V. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kamzik-IISent: 27. července 2006 12:49To: JavaSubject: Re: java.security.Permission Ale paklize by tohle vzdy platilo, pak by byla uplna blbost predefinovat metodu equals, protoze by v ni stacilo porovnavat hascode, kdezto v rodicovske implementaci se porovnavaji pouze instance. - Original Message - From: Richard Malaschitz To: Java Sent: Thursday, July 27, 2006 10:58 AM Subject: Re: java.security.Permission A este si treba pozriet Javadoc k samotnemu objektu java.lang.Object. Tam sa pise o metode hashCode(), ze musi byt implementovana tak aby dva objekty, ktore su equals() musia mat rovnaky hshCode(). !DSPAM:44c8be3a124801581612101!
Re: equals a hashCode (WAS: java.security.Permission)
Jo jo jasne, ale me spis zajima, proc je v ramci vm a ne v ramci aplikace, btw: neni to nahodou to same? - Original Message - From: Kamil Podlesak [EMAIL PROTECTED] To: Java konference@java.cz Sent: Thursday, July 27, 2006 3:25 PM Subject: Re: equals a hashCode (WAS: java.security.Permission) Kamzik-II wrote: O boze, equals tady nekdo pekne vysvetlil na vytiscich knih, hascode vicemene taky chapu, ale neni mi jasne na co je mi dobrej ;-) Hashcode je dobrej v okamziku, kdyz se patricny objekt uklada do hashtabulky ci mnoziny. A to s nejvetsi pravdepodobnosti bude. -- Kamil Podlesak [EMAIL PROTECTED]
RE: equals a hashCode (WAS: java.security.Permission)
V HashMap,Hashtable apod. V nich jsou prvky organizovany dle jejich hashcodu (rychlejsi vyhodnoceni (ne)shody pri hledani) a teprve v zaverecne fazy se pouzijeequals. V hash tabulkach jsou totiz prvky organizovany dle jejich hashcode (kolize se resi prostym retezenim za sebou, nebo do spojoveho seznamu). Tudiz pri dotazech typu containsKey, get apod senejprve hleda dle hashcode a nasledne se provadi porovnani pres equals. Honza -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Kamzik-IISent: Thursday, July 27, 2006 3:25 PMTo: JavaSubject: Re: equals a hashCode (WAS: java.security.Permission) O boze, equals tady nekdo pekne vysvetlil na vytiscich knih, hascode vicemene taky chapu, ale neni mi jasne na co je mi dobrej ;-) - Original Message - From: Vit Novak To: 'Java' Sent: Thursday, July 27, 2006 1:07 PM Subject: equals a hashCode (WAS: java.security.Permission) Zdravim. Doporucuji precist si knizku od pana Blocha (cesky Java efektivne, anglicky Effective Java). Pan Bloch tuto problematiku rozebira pomerne podrobne a myslim, ze tohle patri k zakladnim znalostem, bez kterych dobry Java kod proste psat nebudete. Jedna se totiz o to, ze predefinovani metody equals nebo hashCode vas zavazuje k dodrzeni urcitych pravidel, bez kterych vam treba Collections budou chodit _velmi_ divne nebo vubec. Samozrejme je mozne nadefinovat hashCode a equals implementovat jen jako porovnani hashCode, to ovsem casto neni to, co chcete. Vetsinou jdete obracene nejak si urcite, kdy maji byt dve instance nejake tridy rovne a to naimplementujete. Napriklad budete mozna chtit aby dve ruzne instance tridy mujBigInt, reprezentujici cislo 37, vratily na equals true, ale reprezentace cisla 37 a cisla 56498765654987984632159789 by na equals true vratit nemela. Pak Vas ovsem hashCode zavazuje, aby equals instance vracely stejny hashCode, ale nijak Vas nenuti, aby pro dve instance, ktere equals nejsou byly hashCode ruzne. A zrovna u mujBigIntu hashCode tak, aby pro kazda dve nonequals cisla vratil ruzne hashe, proste nevymyslite. Dalsi vec je, ze kod, kde equals je implementovano jako porovnani hashi, nebude zrovna moc citelny... Toz tak, hodne stesti V. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kamzik-IISent: 27. července 2006 12:49To: JavaSubject: Re: java.security.Permission Ale paklize by tohle vzdy platilo, pak by byla uplna blbost predefinovat metodu equals, protoze by v ni stacilo porovnavat hascode, kdezto v rodicovske implementaci se porovnavaji pouze instance. - Original Message - From: Richard Malaschitz To: Java Sent: Thursday, July 27, 2006 10:58 AM Subject: Re: java.security.Permission A este si treba pozriet Javadoc k samotnemu objektu java.lang.Object. Tam sa pise o metode hashCode(), ze musi byt implementovana tak aby dva objekty, ktore su equals() musia mat rovnaky hshCode().
Re: Zamedzenie viacnasobnemu vykonaniu metody
Ahoj, to je presne jasne aj mne, v povodnom prispevku som pisal ze ako najjednoduchsie riesenie vidim dat danu metodu synchronized. Chcel som len vediet, ci je to spravne riesenie, alebo pouzivate nejaky iny postup. Bojim sa toho, ze ked z jednej synchronized metody zavolam inu synchronized metodu ze mi vznikne deadlock, takze preto sa snazim najst aj ine riesenie. Kamil Podlesak wrote: jeeff wrote: Takze znova opakujem, storno nakupu je len priklad, moze to byt cokolvek co nechcem aby sa cez web rozhranie dalo zavolat 2x nez to zbehne cele do konca. Vobec to nemusi pracovat s databazou. Riesite taketo veci, alebo si poviete, ze taka situacia nenastane a kaslete na to? Samozrejme, pro vsechny multithreadove aplikace (a vubec nezalezi na tom zda jsou webove ci ne) plati, ze je nutne synchronizovat (ci pouzit nejakou sofistikovanejsi techniku). Pouzivani synchronized neni neco navic - je to jedna ze zakladnich veci nutna pri psani v Jave. Vsude a stale. Tim samozrejme nemyslim ze by se vsude melo cpat synchronized, chran buh - jen je nutne nad tim premyslet. -- jeeff
Re: equals a hashCode (WAS: java.security.Permission)
Koukal sem do toho JavaDocu a neni mi teda jasne, k cemu by se to dalo vyuzit... Je tam psano o hashtables, ktere jsem asi taky nepochopil, nebo nwim, asi jsem uplne mimo, myslel jsem, ze je to nejake id objektu, ale pokud stejne cislo muze vracet vic objektu, tak se to neda pouzit ani na to... - Original Message - From: Kamzik-II [EMAIL PROTECTED] To: Java konference@java.cz Sent: Thursday, July 27, 2006 3:30 PM Subject: Re: equals a hashCode (WAS: java.security.Permission) Jo jo jasne, ale me spis zajima, proc je v ramci vm a ne v ramci aplikace, btw: neni to nahodou to same? - Original Message - From: Kamil Podlesak [EMAIL PROTECTED] To: Java konference@java.cz Sent: Thursday, July 27, 2006 3:25 PM Subject: Re: equals a hashCode (WAS: java.security.Permission) Kamzik-II wrote: O boze, equals tady nekdo pekne vysvetlil na vytiscich knih, hascode vicemene taky chapu, ale neni mi jasne na co je mi dobrej ;-) Hashcode je dobrej v okamziku, kdyz se patricny objekt uklada do hashtabulky ci mnoziny. A to s nejvetsi pravdepodobnosti bude. -- Kamil Podlesak [EMAIL PROTECTED]
Re: equals a hashCode (WAS: java.security.Permission)
Aha takze ciste jenom kvuli rychlosti? - Original Message - From: Moravec Jan To: Java Sent: Thursday, July 27, 2006 3:32 PM Subject: RE: equals a hashCode (WAS: java.security.Permission) V HashMap,Hashtable apod. V nich jsou prvky organizovany dle jejich hashcodu (rychlejsi vyhodnoceni (ne)shody pri hledani) a teprve v zaverecne fazy se pouzijeequals. V hash tabulkach jsou totiz prvky organizovany dle jejich hashcode (kolize se resi prostym retezenim za sebou, nebo do spojoveho seznamu). Tudiz pri dotazech typu containsKey, get apod senejprve hleda dle hashcode a nasledne se provadi porovnani pres equals. Honza -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Kamzik-IISent: Thursday, July 27, 2006 3:25 PMTo: JavaSubject: Re: equals a hashCode (WAS: java.security.Permission) O boze, equals tady nekdo pekne vysvetlil na vytiscich knih, hascode vicemene taky chapu, ale neni mi jasne na co je mi dobrej ;-) - Original Message - From: Vit Novak To: 'Java' Sent: Thursday, July 27, 2006 1:07 PM Subject: equals a hashCode (WAS: java.security.Permission) Zdravim. Doporucuji precist si knizku od pana Blocha (cesky Java efektivne, anglicky Effective Java). Pan Bloch tuto problematiku rozebira pomerne podrobne a myslim, ze tohle patri k zakladnim znalostem, bez kterych dobry Java kod proste psat nebudete. Jedna se totiz o to, ze predefinovani metody equals nebo hashCode vas zavazuje k dodrzeni urcitych pravidel, bez kterych vam treba Collections budou chodit _velmi_ divne nebo vubec. Samozrejme je mozne nadefinovat hashCode a equals implementovat jen jako porovnani hashCode, to ovsem casto neni to, co chcete. Vetsinou jdete obracene nejak si urcite, kdy maji byt dve instance nejake tridy rovne a to naimplementujete. Napriklad budete mozna chtit aby dve ruzne instance tridy mujBigInt, reprezentujici cislo 37, vratily na equals true, ale reprezentace cisla 37 a cisla 56498765654987984632159789 by na equals true vratit nemela. Pak Vas ovsem hashCode zavazuje, aby equals instance vracely stejny hashCode, ale nijak Vas nenuti, aby pro dve instance, ktere equals nejsou byly hashCode ruzne. A zrovna u mujBigIntu hashCode tak, aby pro kazda dve nonequals cisla vratil ruzne hashe, proste nevymyslite. Dalsi vec je, ze kod, kde equals je implementovano jako porovnani hashi, nebude zrovna moc citelny... Toz tak, hodne stesti V. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kamzik-IISent: 27. července 2006 12:49To: JavaSubject: Re: java.security.Permission Ale paklize by tohle vzdy platilo, pak by byla uplna blbost predefinovat metodu equals, protoze by v ni stacilo porovnavat hascode, kdezto v rodicovske implementaci se porovnavaji pouze instance. - Original Message - From: Richard Malaschitz To: Java Sent: Thursday, July 27, 2006 10:58 AM Subject: Re: java.security.Permission A este si treba pozriet Javadoc k samotnemu objektu java.lang.Object. Tam sa pise o metode hashCode(), ze musi byt implementovana tak aby dva objekty, ktore su equals() musia mat rovnaky hshCode().
RE: equals a hashCode (WAS: java.security.Permission)
To je daleko starsi koncept. Pamatuji se, ze ve skole jsme se o tom ucili v zakladech programovani a to bylo min 2 roky pred Javou (uz jsemkmet ;) H. -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Kamzik-IISent: Thursday, July 27, 2006 3:41 PMTo: JavaSubject: Re: equals a hashCode (WAS: java.security.Permission) Hm dumyslne ;-) Ti navrhari javy nebyli uplne "blbi" :) - Original Message - From: Moravec Jan To: Java Sent: Thursday, July 27, 2006 3:38 PM Subject: RE: equals a hashCode (WAS: java.security.Permission) Trefa do cernyho ;) Pres hashcode se "nablizite", pres equals dohledate. Princip je ten, ze nedelate equals pres vsechno (u slozitejsich objektu muze byt pomale,treba i u Stringu by ten equals nemusel byt uplne idealni). H. -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Kamzik-IISent: Thursday, July 27, 2006 3:37 PMTo: JavaSubject: Re: equals a hashCode (WAS: java.security.Permission) Aha takze ciste jenom kvuli rychlosti? - Original Message - From: Moravec Jan To: Java Sent: Thursday, July 27, 2006 3:32 PM Subject: RE: equals a hashCode (WAS: java.security.Permission) V HashMap,Hashtable apod. V nich jsou prvky organizovany dle jejich hashcodu (rychlejsi vyhodnoceni (ne)shody pri hledani) a teprve v zaverecne fazy se pouzijeequals. V hash tabulkach jsou totiz prvky organizovany dle jejich hashcode (kolize se resi prostym retezenim za sebou, nebo do spojoveho seznamu). Tudiz pri dotazech typu containsKey, get apod senejprve hleda dle hashcode a nasledne se provadi porovnani pres equals. Honza -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Kamzik-IISent: Thursday, July 27, 2006 3:25 PMTo: JavaSubject: Re: equals a hashCode (WAS: java.security.Permission) O boze, equals tady nekdo pekne vysvetlil na vytiscich knih, hascode vicemene taky chapu, ale neni mi jasne na co je mi dobrej ;-) - Original Message - From: Vit Novak To: 'Java' Sent: Thursday, July 27, 2006 1:07 PM Subject: equals a hashCode (WAS: java.security.Permission) Zdravim. Doporucuji precist si knizku od pana Blocha (cesky Java efektivne, anglicky Effective Java). Pan Bloch tuto problematiku rozebira pomerne podrobne a myslim, ze tohle patri k zakladnim znalostem, bez kterych dobry Java kod proste psat nebudete. Jedna se totiz o to, ze predefinovani metody equals nebo hashCode vas zavazuje k dodrzeni urcitych pravidel, bez kterych vam treba Collections budou chodit _velmi_ divne nebo vubec. Samozrejme je mozne nadefinovat hashCode a equals implementovat jen jako porovnani hashCode, to ovsem casto neni to, co chcete. Vetsinou jdete obracene nejak si urcite, kdy maji byt dve instance nejake tridy rovne a to naimplementujete. Napriklad budete mozna chtit aby dve ruzne instance tridy mujBigInt, reprezentujici cislo 37, vratily na equals true, ale reprezentace cisla 37 a cisla 56498765654987984632159789 by na equals true vratit nemela. Pak Vas ovsem hashCode zavazuje, aby equals instance vracely stejny hashCode, ale nijak Vas nenuti, aby pro dve instance, ktere equals nejsou byly hashCode ruzne. A zrovna u mujBigIntu hashCode tak, aby pro kazda dve nonequals cisla vratil ruzne hashe, proste nevymyslite. Dalsi vec je, ze kod, kde equals je implementovano jako porovnani hashi, nebude zrovna moc citelny... Toz tak, hodne stesti V. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kamzik-IISent: 27. července 2006 12:49To: JavaSubject: Re: java.security.Permission Ale paklize by tohle vzdy platilo, pak by byla uplna blbost predefinovat metodu equals, protoze by v ni stacilo porovnavat hascode, kdezto v
Re: equals a hashCode (WAS: java.security.Permission)
Predstavte si kolekci jako soubor plechovek. Kazda plechovka ma cislo podle hashCode a obsahuje urcity pocet prvku. Dejme tomu, ze se hashCode pro kazdy klic v HashMap pocita tak, ze u kazdeho pismena se zjisti poradi v abecede a pricte se k vyslednemu hashCode. mame klice : Mary(20), Amy(15), May(15), Dirk(34) - hodnoty nemusite prepocitavat...nejsou presne, ale pro ilustraci to staci takze plechovka s cislem 20 bude obsahovat klic Mary, plechovka s cislem 15 klice Amy a May atd. Vyhledavani v kolekcich funguje tak, ze se pomoci hashCode najde spravna plechovka a ta se projde pomoci metody equals! Muzete vracet konstantu jako hashCode, ale to by bylo neefektivni - jedna plechovka a prilis mnoho volani equals. Takze je vyhodne vracet hodnotu vypocitanou z atributu klice. Je dulezite si uvedomit, ze hashCode se musi pocitat tak, aby bylo KONZISTENTNI. Tzn. nemuzeme ho pocitat pomoci transientnich atributu. Mohl byste ulozit jiny hashCode, nez pomoci ktereho budete hledat. Tzn. objekt byste podle daneho hashCode nemohl vubec dohledat. Stejne tak by mohl fungovat nahodne generovany hashCode. Takze hashCode neni jen o rychlosti, ale take o fungovani v kolekcich! Doufam, ze to trochu pomohlo. - Original Message - From: Kamzik-II [EMAIL PROTECTED] To: Java konference@java.cz Sent: Thursday, July 27, 2006 3:36 PM Subject: Re: equals a hashCode (WAS: java.security.Permission) Koukal sem do toho JavaDocu a neni mi teda jasne, k cemu by se to dalo vyuzit... Je tam psano o hashtables, ktere jsem asi taky nepochopil, nebo nwim, asi jsem uplne mimo, myslel jsem, ze je to nejake id objektu, ale pokud stejne cislo muze vracet vic objektu, tak se to neda pouzit ani na to... - Original Message - From: Kamzik-II [EMAIL PROTECTED] To: Java konference@java.cz Sent: Thursday, July 27, 2006 3:30 PM Subject: Re: equals a hashCode (WAS: java.security.Permission) Jo jo jasne, ale me spis zajima, proc je v ramci vm a ne v ramci aplikace, btw: neni to nahodou to same? - Original Message - From: Kamil Podlesak [EMAIL PROTECTED] To: Java konference@java.cz Sent: Thursday, July 27, 2006 3:25 PM Subject: Re: equals a hashCode (WAS: java.security.Permission) Kamzik-II wrote: O boze, equals tady nekdo pekne vysvetlil na vytiscich knih, hascode vicemene taky chapu, ale neni mi jasne na co je mi dobrej ;-) Hashcode je dobrej v okamziku, kdyz se patricny objekt uklada do hashtabulky ci mnoziny. A to s nejvetsi pravdepodobnosti bude. -- Kamil Podlesak [EMAIL PROTECTED] !DSPAM:44c8c0dd124801367610778!
Re: Zamedzenie viacnasobnemu vykonaniu metody
Synchronized nemusi byt idealni, protoze je to synchronized pro cely system a ne jenom pro jednoho uzivatele, navic co kdyz vam to nekdy v budoucnu pobezi na vice strojich ... Ja myslim, ze prave z tohoto duvodu vznikly transakce, tak je kurna pouzivejte ... a ze se az na konci zjisti, ze se neco delalo zbytecne, no pak tu mame rollback, ne? jeeff napsal(a): Ahoj, to je presne jasne aj mne, v povodnom prispevku som pisal ze ako najjednoduchsie riesenie vidim dat danu metodu synchronized. Chcel som len vediet, ci je to spravne riesenie, alebo pouzivate nejaky iny postup. Bojim sa toho, ze ked z jednej synchronized metody zavolam inu synchronized metodu ze mi vznikne deadlock, takze preto sa snazim najst aj ine riesenie. Kamil Podlesak wrote: jeeff wrote: Takze znova opakujem, storno nakupu je len priklad, moze to byt cokolvek co nechcem aby sa cez web rozhranie dalo zavolat 2x nez to zbehne cele do konca. Vobec to nemusi pracovat s databazou. Riesite taketo veci, alebo si poviete, ze taka situacia nenastane a kaslete na to? Samozrejme, pro vsechny multithreadove aplikace (a vubec nezalezi na tom zda jsou webove ci ne) plati, ze je nutne synchronizovat (ci pouzit nejakou sofistikovanejsi techniku). Pouzivani synchronized neni neco navic - je to jedna ze zakladnich veci nutna pri psani v Jave. Vsude a stale. Tim samozrejme nemyslim ze by se vsude melo cpat synchronized, chran buh - jen je nutne nad tim premyslet. -- Jiří Mareš (mailto:[EMAIL PROTECTED]) ČSAD SVT Praha, s.r.o. (http://www.svt.cz) Czech Republic
Re: equals a hashCode (WAS: java.security.Permission)
Kamzik-II wrote: Koukal sem do toho JavaDocu a neni mi teda jasne, k cemu by se to dalo vyuzit... Je tam psano o hashtables, ktere jsem asi taky nepochopil, nebo nwim, asi jsem uplne mimo, myslel jsem, ze je to nejake id objektu, ale pokud stejne cislo muze vracet vic objektu, tak se to neda pouzit ani na to... Prosim, prosim, na webu jsou tisice a tisice ruznych popisu hashtabulek a na jakem principu funguji. Popis teto datove struktury sem nepatri, navic KAZDY programator ji musi znat, protoze se jedna o jednu z nejpouzivanejsich datovych struktur (obzvlaste v Jave). -- Kamil Podlesak [EMAIL PROTECTED]
Re: equals a hashCode (WAS: java.security.Permission)
Moravec Jan wrote: To je daleko starsi koncept. Pamatuji se, ze ve skole jsme se o tom ucili v zakladech programovani a to bylo min 2 roky pred Javou (uz jsem kmet ;) H. Myslim, ze hashovani vymysleli 50 letech v IBM :-)
Re: equals a hashCode (WAS: java.security.Permission)
To nic nemeni na tom, ze je to genialni a pritom tak jednoduche;-) - Original Message - From: Moravec Jan To: Java Sent: Thursday, July 27, 2006 3:43 PM Subject: RE: equals a hashCode (WAS: java.security.Permission) To je daleko starsi koncept. Pamatuji se, ze ve skole jsme se o tom ucili v zakladech programovani a to bylo min 2 roky pred Javou (uz jsemkmet ;) H. -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Kamzik-IISent: Thursday, July 27, 2006 3:41 PMTo: JavaSubject: Re: equals a hashCode (WAS: java.security.Permission) Hm dumyslne ;-) Ti navrhari javy nebyli uplne "blbi" :) - Original Message - From: Moravec Jan To: Java Sent: Thursday, July 27, 2006 3:38 PM Subject: RE: equals a hashCode (WAS: java.security.Permission) Trefa do cernyho ;) Pres hashcode se "nablizite", pres equals dohledate. Princip je ten, ze nedelate equals pres vsechno (u slozitejsich objektu muze byt pomale,treba i u Stringu by ten equals nemusel byt uplne idealni). H. -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Kamzik-IISent: Thursday, July 27, 2006 3:37 PMTo: JavaSubject: Re: equals a hashCode (WAS: java.security.Permission) Aha takze ciste jenom kvuli rychlosti? - Original Message - From: Moravec Jan To: Java Sent: Thursday, July 27, 2006 3:32 PM Subject: RE: equals a hashCode (WAS: java.security.Permission) V HashMap,Hashtable apod. V nich jsou prvky organizovany dle jejich hashcodu (rychlejsi vyhodnoceni (ne)shody pri hledani) a teprve v zaverecne fazy se pouzijeequals. V hash tabulkach jsou totiz prvky organizovany dle jejich hashcode (kolize se resi prostym retezenim za sebou, nebo do spojoveho seznamu). Tudiz pri dotazech typu containsKey, get apod senejprve hleda dle hashcode a nasledne se provadi porovnani pres equals. Honza -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Kamzik-IISent: Thursday, July 27, 2006 3:25 PMTo: JavaSubject: Re: equals a hashCode (WAS: java.security.Permission) O boze, equals tady nekdo pekne vysvetlil na vytiscich knih, hascode vicemene taky chapu, ale neni mi jasne na co je mi dobrej ;-) - Original Message - From: Vit Novak To: 'Java' Sent: Thursday, July 27, 2006 1:07 PM Subject: equals a hashCode (WAS: java.security.Permission) Zdravim. Doporucuji precist si knizku od pana Blocha (cesky Java efektivne, anglicky Effective Java). Pan Bloch tuto problematiku rozebira pomerne podrobne a myslim, ze tohle patri k zakladnim znalostem, bez kterych dobry Java kod proste psat nebudete. Jedna se totiz o to, ze predefinovani metody equals nebo hashCode vas zavazuje k dodrzeni urcitych pravidel, bez kterych vam treba Collections budou chodit _velmi_ divne nebo vubec. Samozrejme je mozne nadefinovat hashCode a equals implementovat jen jako porovnani hashCode, to ovsem casto neni to, co chcete. Vetsinou jdete obracene nejak si urcite, kdy maji byt dve instance nejake tridy rovne a to naimplementujete. Napriklad budete mozna chtit aby dve ruzne instance tridy mujBigInt, reprezentujici cislo 37, vratily na equals true, ale reprezentace cisla 37 a cisla 56498765654987984632159789 by na equals true vratit nemela. Pak Vas ovsem hashCode zavazuje, aby equals instance vracely stejny hashCode, ale nijak Vas nenuti, aby pro dve instance, ktere equals nejsou byly hashCode ruzne. A zrovna u mujBigIntu hashCode tak, aby pro kazda dve nonequals cisla vratil ruzne hashe, proste nevymyslite. Dalsi vec je, ze kod, kde equals je implementovano jako porovnani hashi, nebude zrovna moc citelny... Toz tak, hodne stesti V.
Re: equals a hashCode (WAS: java.security.Permission)
Kamil Podlesak wrote: Kamzik-II wrote: Koukal sem do toho JavaDocu a neni mi teda jasne, k cemu by se to dalo vyuzit... Je tam psano o hashtables, ktere jsem asi taky nepochopil, nebo nwim, asi jsem uplne mimo, myslel jsem, ze je to nejake id objektu, ale pokud stejne cislo muze vracet vic objektu, tak se to neda pouzit ani na to... Prosim, prosim, na webu jsou tisice a tisice ruznych popisu hashtabulek a na jakem principu funguji. Popis teto datove struktury sem nepatri, navic KAZDY programator ji musi znat, protoze se jedna o jednu z nejpouzivanejsich datovych struktur (obzvlaste v Jave). Jo, kazdy spravny programator by mel mit doma v knihovnicce neco jako http://www.mpi-sb.mpg.de/~mehlhorn/DatAlgbooks.html Stejne tak by mel kazdy programator svuj program dokazat, jak si to predstavoval pan Dijkstra ;-)
Re: equals a hashCode (WAS: java.security.Permission)
Tady je opet potreba se na to podivat skrz teorii algoritmu. Ale jinak jak pisou ostatni na webu je spousta popisu ktere to vysvetli podrobneji a lepe. Hastable, jsou tabulky zalozene na slovniku. tj, na dvojicich (klic, jeho vyznam). Pricemz zakladni vyznam, je v rychlejsim nalezeni hodnoty k danemu klici. Kdyz si tedy predstavite nejaky slovnik, treba AN-CZ, v nem mate nejaky klic, ten klic muze mit v cestine vice vyznamu. Zde pak zalezi na konkretni implementaci hashovaci tabulky. Jedna z implementaci napriklad funguje tak, ze spocita hashcode klice a bude to jeho umisteni v tabulce, pokud ale nastane pripad, ze nejaky objekt ma stejny hashcode, a jeho pozice je jiz obsazena, tak nalezne prvni volne misto v tabulce za timto objektem a tam jej ulozi. Samozrejme, jen tehdy,pokud to tabulka dovoli (muze prohlasit, s hashcodem tam muze byt jen jeden stejny objekt a pak ho prepise). Dalsi implementace je takova, ze na pozici s danou hodnotou hashcode ma ulozeny nejakou jinou strukturu (pole, kolekci apod).a ta obsahuje vsechny objekty se stejnym hashcode. Pokud potom vyzaduje aplikace nalezt konkretni objekt, tak pak zalezi zda vrati na zaklade hashcode vsechny, nebo pak prochazi jinym zpusobem tu strukturu obsahujici dane objekty (napr. pomoci metody equals). Lumi(r) Kamzik-II wrote: Koukal sem do toho JavaDocu a neni mi teda jasne, k cemu by se to dalo vyuzit... Je tam psano o hashtables, ktere jsem asi taky nepochopil, nebo nwim, asi jsem uplne mimo, myslel jsem, ze je to nejake id objektu, ale pokud stejne cislo muze vracet vic objektu, tak se to neda pouzit ani na to... - Original Message - From: Kamzik-II [EMAIL PROTECTED] To: Java konference@java.cz Sent: Thursday, July 27, 2006 3:30 PM Subject: Re: equals a hashCode (WAS: java.security.Permission) Jo jo jasne, ale me spis zajima, proc je v ramci vm a ne v ramci aplikace, btw: neni to nahodou to same? - Original Message - From: Kamil Podlesak [EMAIL PROTECTED] To: Java konference@java.cz Sent: Thursday, July 27, 2006 3:25 PM Subject: Re: equals a hashCode (WAS: java.security.Permission) Kamzik-II wrote: O boze, equals tady nekdo pekne vysvetlil na vytiscich knih, hascode vicemene taky chapu, ale neni mi jasne na co je mi dobrej ;-) Hashcode je dobrej v okamziku, kdyz se patricny objekt uklada do hashtabulky ci mnoziny. A to s nejvetsi pravdepodobnosti bude. -- Kamil Podlesak [EMAIL PROTECTED]
Re: Zamedzenie viacnasobnemu vykonaniu metody
jeeff wrote:
Ahoj,
to je presne jasne aj mne, v povodnom prispevku som pisal ze ako
najjednoduchsie riesenie vidim dat danu metodu synchronized. Chcel som
len vediet, ci je to spravne riesenie, alebo pouzivate nejaky iny postup.
Dat danou metodu synchronized neni spravne reseni, je to hack a skutecne
je nebezpecny (viz dale).
Staci synchronizovat jen nezbytne nutnou sekci:
synchronized (nakupBean) {
if (nakupBean.isStornovany()) return false;
nakupBean.setStornovany(true);
}
Take by slo pouzit java.util.concurrent.AtomicBoolean (java 1.5+).
Bojim sa toho, ze ked z jednej synchronized metody zavolam inu
synchronized metodu ze mi vznikne deadlock, takze preto sa snazim najst
aj ine riesenie.
Deadlock v Jave vznikne jen tak, ze si ruzna vlakna zamknou vice
stejnych monitoru, ale v navzajem ruznem poradi. To se nestane, pokud
jsou synchronized sekce a metody pouzity jen tam kde je to nutne (datove
struktury, operace ktere musi byt atomicke a podobne). V podstate se to
muze stat jenom v pripade, ze se na vice vlaken vzpomene pozde a do
hotoveho kodu se nasazi klicova slovicka synchronized u tech hlavnich
metod (coz je bohuzel tento pripad).
To je to o cem jsem psal - na synchronizaci je nutne myslet stale.
Jedine tak se synchronizuji jen ty opravdu nejmensi nutne useky. A neni
nutne se nejak synchronized vyhybat a pak resit nejake otazky jako zda
ho vyuzit nebo ne... nejde o zadnou cernou magii.
--
Kamil Podlesak [EMAIL PROTECTED]
Re: Zamedzenie viacnasobnemu vykonaniu metody
Pokud jde o synchronized, tak jsem si zrovna nedavno nechutne nabehl, protoze to co bylo uvnitr synchronized bloku trvalo dele nez jsem si myslel a pak transformace malinkeho XSLT trvala jednou 7 minut a jednou mene nez vterinu, protoze vsichni cekali ve fronte pred synchronized blokem. Rozhodne souhlasim s Jirim, ze na datovou konzistenci ma dohlizet databaze a ne business logika. Jinak vam proste jednou nekdo sprasi data pres TOAD nebo sqlplus a budete se divit ;-) Tom Jiří Mareš napsal(a): Synchronized nemusi byt idealni, protoze je to synchronized pro cely system a ne jenom pro jednoho uzivatele, navic co kdyz vam to nekdy v budoucnu pobezi na vice strojich ... Ja myslim, ze prave z tohoto duvodu vznikly transakce, tak je kurna pouzivejte ... a ze se az na konci zjisti, ze se neco delalo zbytecne, no pak tu mame rollback, ne? jeeff napsal(a): Ahoj, to je presne jasne aj mne, v povodnom prispevku som pisal ze ako najjednoduchsie riesenie vidim dat danu metodu synchronized. Chcel som len vediet, ci je to spravne riesenie, alebo pouzivate nejaky iny postup. Bojim sa toho, ze ked z jednej synchronized metody zavolam inu synchronized metodu ze mi vznikne deadlock, takze preto sa snazim najst aj ine riesenie. Kamil Podlesak wrote: jeeff wrote: Takze znova opakujem, storno nakupu je len priklad, moze to byt cokolvek co nechcem aby sa cez web rozhranie dalo zavolat 2x nez to zbehne cele do konca. Vobec to nemusi pracovat s databazou. Riesite taketo veci, alebo si poviete, ze taka situacia nenastane a kaslete na to? Samozrejme, pro vsechny multithreadove aplikace (a vubec nezalezi na tom zda jsou webove ci ne) plati, ze je nutne synchronizovat (ci pouzit nejakou sofistikovanejsi techniku). Pouzivani synchronized neni neco "navic" - je to jedna ze zakladnich veci nutna pri psani v Jave. Vsude a stale. Tim samozrejme nemyslim ze by se vsude melo cpat synchronized, chran buh - jen je nutne nad tim premyslet.
Re: equals a hashCode (WAS: java.security.Permission)
Ne;-) - Original Message - From: Kamzik-II [EMAIL PROTECTED] To: Java konference@java.cz Sent: Thursday, July 27, 2006 4:11 PM Subject: Re: equals a hashCode (WAS: java.security.Permission) no equals a hashcode uz chapu ;-) jeste jedna otazka ohledne kolekci, muze kolekce Map mit pro jeden klic vice objektu? - Original Message - From: Stanislav Ošmera [EMAIL PROTECTED] To: Java konference@java.cz Sent: Thursday, July 27, 2006 4:04 PM Subject: Re: equals a hashCode (WAS: java.security.Permission) Mimo jine se doporucuje aby funkce ktera vraci hashcode byla velmi jednoducha a rychla protoze se pouzije jako prvni a nejcasteji (kdyz je ruzny hashcode tak se jiz dale nic nezjistuje) A az pak funkce equals muze byt velmi slozita na vyhodnoceni. Napriklad mam slozity objekt ktery ma spoustu atributu. Hashcode vytvorim jen treba pouzitim 3 z nich ktery jsou primitivni typy, kdezto pri equals porovnavam vsechny atributy a to u nekterych muze znamenat porovnavani jinych objektu s podobnou slozitosti. Ale opravdu bude lepe si precist nejakou knizku o tehlech hlavnich algoritmickych myslenkach ktere jsou v Jave, ten zminovany Bloch je treba zrovna na tohle vyborny. P.S. jinak tomu spojeni equal a hashCode se rika equals contract -- Stanislav Ošmera Work: +44 (0)2075 980 348 Cell: +44 (0)7914 635 412 !DSPAM:44c8c935124803984916995!
Re: equals a hashCode (WAS: java.security.Permission)
V tom pripade teda nechapu, jak muze hashtable mit vic objektu pro jeden klic, kdyz je to vlastne implementace hashmapy, ktera je odvozena od map? - Original Message - From: Pavel Kubal [EMAIL PROTECTED] To: Java konference@java.cz Sent: Thursday, July 27, 2006 4:09 PM Subject: Re: equals a hashCode (WAS: java.security.Permission) Ne;-) - Original Message - From: Kamzik-II [EMAIL PROTECTED] To: Java konference@java.cz Sent: Thursday, July 27, 2006 4:11 PM Subject: Re: equals a hashCode (WAS: java.security.Permission) no equals a hashcode uz chapu ;-) jeste jedna otazka ohledne kolekci, muze kolekce Map mit pro jeden klic vice objektu? - Original Message - From: Stanislav Ošmera [EMAIL PROTECTED] To: Java konference@java.cz Sent: Thursday, July 27, 2006 4:04 PM Subject: Re: equals a hashCode (WAS: java.security.Permission) Mimo jine se doporucuje aby funkce ktera vraci hashcode byla velmi jednoducha a rychla protoze se pouzije jako prvni a nejcasteji (kdyz je ruzny hashcode tak se jiz dale nic nezjistuje) A az pak funkce equals muze byt velmi slozita na vyhodnoceni. Napriklad mam slozity objekt ktery ma spoustu atributu. Hashcode vytvorim jen treba pouzitim 3 z nich ktery jsou primitivni typy, kdezto pri equals porovnavam vsechny atributy a to u nekterych muze znamenat porovnavani jinych objektu s podobnou slozitosti. Ale opravdu bude lepe si precist nejakou knizku o tehlech hlavnich algoritmickych myslenkach ktere jsou v Jave, ten zminovany Bloch je treba zrovna na tohle vyborny. P.S. jinak tomu spojeni equal a hashCode se rika equals contract -- Stanislav Ošmera Work: +44 (0)2075 980 348 Cell: +44 (0)7914 635 412 !DSPAM:44c8c935124803984916995!
Re: equals a hashCode (WAS: java.security.Permission)
API dokumentace pravi : metoda put() : Associates the specified value with the specified key in this map (optional operation). If the map previously contained a mapping for this key, the old value is replaced by the specified value. (A map m is said to contain a mapping for a key k if and only if m.containsKey(k) would return true.)) Jak by mohla mit mapa vic objektu pro jeden klic? Pavel Kubal - Original Message - From: Kamzik-II [EMAIL PROTECTED] To: Java konference@java.cz Sent: Thursday, July 27, 2006 4:15 PM Subject: Re: equals a hashCode (WAS: java.security.Permission) V tom pripade teda nechapu, jak muze hashtable mit vic objektu pro jeden klic, kdyz je to vlastne implementace hashmapy, ktera je odvozena od map? - Original Message - From: Pavel Kubal [EMAIL PROTECTED] To: Java konference@java.cz Sent: Thursday, July 27, 2006 4:09 PM Subject: Re: equals a hashCode (WAS: java.security.Permission) Ne;-) - Original Message - From: Kamzik-II [EMAIL PROTECTED] To: Java konference@java.cz Sent: Thursday, July 27, 2006 4:11 PM Subject: Re: equals a hashCode (WAS: java.security.Permission) no equals a hashcode uz chapu ;-) jeste jedna otazka ohledne kolekci, muze kolekce Map mit pro jeden klic vice objektu? - Original Message - From: Stanislav Ošmera [EMAIL PROTECTED] To: Java konference@java.cz Sent: Thursday, July 27, 2006 4:04 PM Subject: Re: equals a hashCode (WAS: java.security.Permission) Mimo jine se doporucuje aby funkce ktera vraci hashcode byla velmi jednoducha a rychla protoze se pouzije jako prvni a nejcasteji (kdyz je ruzny hashcode tak se jiz dale nic nezjistuje) A az pak funkce equals muze byt velmi slozita na vyhodnoceni. Napriklad mam slozity objekt ktery ma spoustu atributu. Hashcode vytvorim jen treba pouzitim 3 z nich ktery jsou primitivni typy, kdezto pri equals porovnavam vsechny atributy a to u nekterych muze znamenat porovnavani jinych objektu s podobnou slozitosti. Ale opravdu bude lepe si precist nejakou knizku o tehlech hlavnich algoritmickych myslenkach ktere jsou v Jave, ten zminovany Bloch je treba zrovna na tohle vyborny. P.S. jinak tomu spojeni equal a hashCode se rika equals contract -- Stanislav Ošmera Work: +44 (0)2075 980 348 Cell: +44 (0)7914 635 412 !DSPAM:44c8ca12124801431714180!
Re: Zamedzenie viacnasobnemu vykonaniu metody
Kamil Podlesak wrote:
jeeff wrote:
Ahoj,
to je presne jasne aj mne, v povodnom prispevku som pisal ze ako
najjednoduchsie riesenie vidim dat danu metodu synchronized. Chcel som
len vediet, ci je to spravne riesenie, alebo pouzivate nejaky iny
postup.
Dat danou metodu synchronized neni spravne reseni, je to hack a
skutecne je nebezpecny (viz dale).
Staci synchronizovat jen nezbytne nutnou sekci:
synchronized (nakupBean) {
if (nakupBean.isStornovany()) return false;
nakupBean.setStornovany(true);
}
Take by slo pouzit java.util.concurrent.AtomicBoolean (java 1.5+).
nad tymto som presne uvazoval, respektive synchronizoval by som to nad
userom co spravil ten nakup. Totiz volanie
nakupBean.setStornovany(true); ja teraz volam az ked zbehne vsetko pred
tym (vratenie penazi na ucet nakupujuceho). Ale teoreticky to mozem
spravit aj takto nazaciatku a keby sa mi z nejakeho dovodu nepodarilo
spravit financnu tranzakciu tak to stornovanie zrusim.
Jiri Mares radil pouzit tranzakcie, tiez su tu rady, ze datovu
konzistenciu ma drzat databaza, ale co ked vratenie penazi na ucet
nakupujuceho je nejake XML volanie do banky. Cize sa to neda spravit
ako nejaka databazova tranzakcia, ani to databaza nemoze riesit svojou
konzistenciou.
Bojim sa toho, ze ked z jednej synchronized metody zavolam inu
synchronized metodu ze mi vznikne deadlock, takze preto sa snazim najst
aj ine riesenie.
Deadlock v Jave vznikne jen tak, ze si ruzna vlakna zamknou vice
stejnych monitoru, ale v navzajem ruznem poradi. To se nestane, pokud
jsou synchronized sekce a metody pouzity jen tam kde je to nutne
(datove struktury, operace ktere musi byt atomicke a podobne). V
podstate se to muze stat jenom v pripade, ze se na vice vlaken
vzpomene pozde a do hotoveho kodu se nasazi klicova slovicka
synchronized u tech hlavnich metod (coz je bohuzel tento pripad).
To je to o cem jsem psal - na synchronizaci je nutne myslet stale.
Jedine tak se synchronizuji jen ty opravdu nejmensi nutne useky. A
neni nutne se nejak synchronized vyhybat a pak resit nejake otazky
jako zda ho vyuzit nebo ne... nejde o zadnou cernou magii.
hej, ved prave na tu synchronizaciu myslim, doteraz som to ziadno
neriesil, ale pri financnych operaciach to moze byt problem... Ak by sa
jednalo len o to storno nie je problem ked sa to do databazy zapise aj
10x, ze atribut storno je true. Problem je v tom, ze ked sa vykona
storno vratim peniaze na ucet nakupujuceho a to by som bol nerad, keby
sa niekomu podarilo viac krat.
--
jeeff
RE: Zamedzenie viacnasobnemu vykonaniu metody
Transakce samozrejme, ale to Vase reseni s triggerem je hack. fil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tomas Hubalek Sent: Thursday, July 27, 2006 4:12 PM To: Java Subject: Re: Zamedzenie viacnasobnemu vykonaniu metody Pokud jde o synchronized, tak jsem si zrovna nedavno nechutne nabehl, protoze to co bylo uvnitr synchronized bloku trvalo dele nez jsem si myslel a pak transformace malinkeho XSLT trvala jednou 7 minut a jednou mene nez vterinu, protoze vsichni cekali ve fronte pred synchronized blokem. Rozhodne souhlasim s Jirim, ze na datovou konzistenci ma dohlizet databaze a ne business logika. Jinak vam proste jednou nekdo sprasi data pres TOAD nebo sqlplus a budete se divit ;-) Tom Jiří Mareš napsal(a): Synchronized nemusi byt idealni, protoze je to synchronized pro cely system a ne jenom pro jednoho uzivatele, navic cokdyz vam to nekdy v budoucnu pobezi na vice strojich ...Ja myslim, ze prave z tohoto duvodu vznikly transakce, tak je kurna pouzivejte ... a ze se az na konci zjisti, ze seneco delalo zbytecne, no pak tu mame rollback, ne?jeeff napsal(a): Ahoj,to je presne jasne aj mne, v povodnom prispevku som pisal ze akonajjednoduchsie riesenie vidim dat danu metodu synchronized. Chcel somlen vediet, ci je to spravne riesenie, alebo pouzivate nejaky iny postup.Bojim sa toho, ze ked z jednej synchronized metody zavolam inusynchronized metodu ze mi vznikne deadlock, takze preto sa snazim najstaj ine riesenie.Kamil Podlesak wrote: jeeff wrote: Takze znova opakujem, storno nakupu je len priklad, moze to bytcokolvek co nechcem aby sa cez web rozhranie dalo zavolat 2x nez tozbehne cele do konca. Vobec to nemusi pracovat s databazou. Riesitetaketo veci, alebo si poviete, ze taka situacia nenastane a kasletena to? Samozrejme, pro vsechny multithreadove aplikace (a vubec nezalezi natom zda jsou webove ci ne) plati, ze je nutne synchronizovat (cipouzit nejakou sofistikovanejsi techniku).Pouzivani synchronized neni neco navic - je to jedna ze zakladnichveci nutna pri psani v Jave. Vsude a stale. Tim samozrejme nemyslim zeby se vsude melo cpat synchronized, chran buh - jen je nutne nad timpremyslet.
Re: equals a hashCode (WAS: java.security.Permission)
Uz ctu... a stydim se ;-) - Original Message - From: Jiri Fabian [EMAIL PROTECTED] To: 'Java' konference@java.cz Sent: Thursday, July 27, 2006 4:30 PM Subject: RE: equals a hashCode (WAS: java.security.Permission) To je diskuze o @. Jeden o voze, druhej o koze. Slovnik je pred tebou skrytej, takze ten zahashovanej vlacek k jednomu policku nevidis, nestaras o nej - musis jen mit hashcode() i equals(). Kamziku, nespamuj a mazej si cist. Pripominas mi malyho fakana, co taha tatu za kosili a furt se ho dokolecka pta k cemu je volant. fil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lumír Návrat Sent: Thursday, July 27, 2006 4:20 PM To: Java Subject: Re: equals a hashCode (WAS: java.security.Permission) Protoze, nejcastejsi reseni je, ze si to managujete sam. Zde je totiz rozdil, mezi teorii a JAVou, Java totiz nepovoluje mit vice objektu k jednomu klici, takze se to obchazi tak, ze si k danemu klici vlozite jako hodnotu nejakou kolekci a v ni si udrzujete objekty patrici danemu klici. Zda ta dalsi kolekce je hashmap, ci nejaky list, set apod. je jiz na Vas a na potrebach projektu Lumi(r) Kamzik-II wrote: V tom pripade teda nechapu, jak muze hashtable mit vic objektu pro jeden klic, kdyz je to vlastne implementace hashmapy, ktera je odvozena od map? - Original Message - From: Pavel Kubal [EMAIL PROTECTED] To: Java konference@java.cz Sent: Thursday, July 27, 2006 4:09 PM Subject: Re: equals a hashCode (WAS: java.security.Permission) Ne;-) - Original Message - From: Kamzik-II [EMAIL PROTECTED] To: Java konference@java.cz Sent: Thursday, July 27, 2006 4:11 PM Subject: Re: equals a hashCode (WAS: java.security.Permission) no equals a hashcode uz chapu ;-) jeste jedna otazka ohledne kolekci, muze kolekce Map mit pro jeden klic vice objektu? - Original Message - From: Stanislav Ošmera [EMAIL PROTECTED] To: Java konference@java.cz Sent: Thursday, July 27, 2006 4:04 PM Subject: Re: equals a hashCode (WAS: java.security.Permission) Mimo jine se doporucuje aby funkce ktera vraci hashcode byla velmi jednoducha a rychla protoze se pouzije jako prvni a nejcasteji (kdyz je ruzny hashcode tak se jiz dale nic nezjistuje) A az pak funkce equals muze byt velmi slozita na vyhodnoceni. Napriklad mam slozity objekt ktery ma spoustu atributu. Hashcode vytvorim jen treba pouzitim 3 z nich ktery jsou primitivni typy, kdezto pri equals porovnavam vsechny atributy a to u nekterych muze znamenat porovnavani jinych objektu s podobnou slozitosti. Ale opravdu bude lepe si precist nejakou knizku o tehlech hlavnich algoritmickych myslenkach ktere jsou v Jave, ten zminovany Bloch je treba zrovna na tohle vyborny. P.S. jinak tomu spojeni equal a hashCode se rika equals contract -- Stanislav Ošmera Work: +44 (0)2075 980 348 Cell: +44 (0)7914 635 412 !DSPAM:44c8c935124803984916995!
Re: Zamedzenie viacnasobnemu vykonaniu metody
jeeff wrote: nad tymto som presne uvazoval, respektive synchronizoval by som to nad userom co spravil ten nakup. Totiz volanie nakupBean.setStornovany(true); ja teraz volam az ked zbehne vsetko pred tym (vratenie penazi na ucet nakupujuceho). Ale teoreticky to mozem spravit aj takto nazaciatku a keby sa mi z nejakeho dovodu nepodarilo spravit financnu tranzakciu tak to stornovanie zrusim. Jiri Mares radil pouzit tranzakcie, tiez su tu rady, ze datovu konzistenciu ma drzat databaza, ale co ked vratenie penazi na ucet nakupujuceho je nejake XML volanie do banky. Cize sa to neda spravit ako nejaka databazova tranzakcia, ani to databaza nemoze riesit svojou konzistenciou. Potom at most once semantika neni mozna. Musite i odeslani penez do banky napsat jako idempotentni. Lukas
Re: equals a hashCode (WAS: java.security.Permission)
Kdyz se podivate do API, tak zjistite, ze Dictionary je obsolete a ma se pouzit Map, jenze zaroven to je stale abstraktni trida, ktera Vam implementuje to spolecne pro vsechny (key, value) colekce. Jednim ze zasadnich zvratu ve vyvoji Javy, byl prepracovani Collections API mezi verzemi JAVy 1.1.x a 1.2.x a vyssi. S ohledem na implementaci HashMap, HashTable v JAVe je ten muj priklad, se slovnikem opravdu mirne zavadejici, ale podle obecne teorie v tom problem neni. Samozjreme si muzete napsat vlastni implementaci HashMapy, ktera Vam mnou popsane reseni vice objektu pro klic bude resit sama. Mozna jej dokonce jiz naleznete implementovane v baliku Apache Collections. (Vim, ze zde minimalne existuje podpora pro hastamap s klicem, skladajicim, se ze dvou objektu. Lumi(r) Kamzik-II wrote: a proc se to obchazi a nepouzije se rozhranni Dictionary? - Original Message - From: Lumír Návrat [EMAIL PROTECTED] To: Java konference@java.cz Sent: Thursday, July 27, 2006 4:19 PM Subject: Re: equals a hashCode (WAS: java.security.Permission) Protoze, nejcastejsi reseni je, ze si to managujete sam. Zde je totiz rozdil, mezi teorii a JAVou, Java totiz nepovoluje mit vice objektu k jednomu klici, takze se to obchazi tak, ze si k danemu klici vlozite jako hodnotu nejakou kolekci a v ni si udrzujete objekty patrici danemu klici. Zda ta dalsi kolekce je hashmap, ci nejaky list, set apod. je jiz na Vas a na potrebach projektu Lumi(r) Kamzik-II wrote: V tom pripade teda nechapu, jak muze hashtable mit vic objektu pro jeden klic, kdyz je to vlastne implementace hashmapy, ktera je odvozena od map? - Original Message - From: Pavel Kubal [EMAIL PROTECTED] To: Java konference@java.cz Sent: Thursday, July 27, 2006 4:09 PM Subject: Re: equals a hashCode (WAS: java.security.Permission) Ne;-) - Original Message - From: Kamzik-II [EMAIL PROTECTED] To: Java konference@java.cz Sent: Thursday, July 27, 2006 4:11 PM Subject: Re: equals a hashCode (WAS: java.security.Permission) no equals a hashcode uz chapu ;-) jeste jedna otazka ohledne kolekci, muze kolekce Map mit pro jeden klic vice objektu? - Original Message - From: Stanislav Ošmera [EMAIL PROTECTED] To: Java konference@java.cz Sent: Thursday, July 27, 2006 4:04 PM Subject: Re: equals a hashCode (WAS: java.security.Permission) Mimo jine se doporucuje aby funkce ktera vraci hashcode byla velmi jednoducha a rychla protoze se pouzije jako prvni a nejcasteji (kdyz je ruzny hashcode tak se jiz dale nic nezjistuje) A az pak funkce equals muze byt velmi slozita na vyhodnoceni. Napriklad mam slozity objekt ktery ma spoustu atributu. Hashcode vytvorim jen treba pouzitim 3 z nich ktery jsou primitivni typy, kdezto pri equals porovnavam vsechny atributy a to u nekterych muze znamenat porovnavani jinych objektu s podobnou slozitosti. Ale opravdu bude lepe si precist nejakou knizku o tehlech hlavnich algoritmickych myslenkach ktere jsou v Jave, ten zminovany Bloch je treba zrovna na tohle vyborny. P.S. jinak tomu spojeni equal a hashCode se rika equals contract -- Stanislav Ošmera Work: +44 (0)2075 980 348 Cell: +44 (0)7914 635 412 !DSPAM:44c8c935124803984916995!
hashCode equals
Mimochodem dekuju za pomoc, sice jsem dotedka tyhle 2 metody nikde nepotreboval, ale tak nejak tusim, ze by si mi brzy vymstili... Diky moc
Re: equals, hashcode, permission
zakladni zacatecnicka chyba:
- porovnava se pres equal metodu
- muze vam to padnout na NullPointerException
Kamzik-II napsal(a):
Tak jsem si to vsechno vyzkousel,
a implementace by mela tim padem vypadat asi takhle:
class CustomPermission
{
public CustomPermission ( String name )
{
super ( name );
}
...
public int hashCode ()
{
return this.getName ().hashCode ();
}
public boolean equals ( Object object )
{
if ( object instanceof CustomPermission )
{
CustomPermission cp = (CustomPermission) object;
if ( ( cp.getName == this.getName () ) cp.getActions () ==
this.getActions () )
return true;
}
return false;
}
}
nemam tam nejakou salamounskou chybu?
--
S pozdravem Roman Dagi Pichlik
/* http://www.sweb.cz/pichlik/ Blog pro kodery */
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
Re: equals, hashcode, permission
Jj dost casto na to zapominam, zil jsem dlouho
v php svete a navykl jsem si na type-hinting, kterej
ale v php funguje trochu jinak (neumoznuje null).
Je tam jeste nejaka chyba?
- Original Message -
From: Roman Pichlik [EMAIL PROTECTED]
To: Java konference@java.cz
Sent: Thursday, July 27, 2006 5:14 PM
Subject: Re: equals, hashcode, permission
zakladni zacatecnicka chyba:
- porovnava se pres equal metodu
- muze vam to padnout na NullPointerException
Kamzik-II napsal(a):
Tak jsem si to vsechno vyzkousel,
a implementace by mela tim padem vypadat asi takhle:
class CustomPermission
{
public CustomPermission ( String name )
{
super ( name );
}
...
public int hashCode ()
{
return this.getName ().hashCode ();
}
public boolean equals ( Object object )
{
if ( object instanceof CustomPermission )
{
CustomPermission cp = (CustomPermission) object;
if ( ( cp.getName == this.getName () ) cp.getActions () ==
this.getActions () )
return true;
}
return false;
}
}
nemam tam nejakou salamounskou chybu?
--
S pozdravem Roman Dagi Pichlik
/* http://www.sweb.cz/pichlik/ Blog pro kodery */
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
Re: Zamedzenie viacnasobnemu vykonaniu metody
Jiri Mares radil pouzit tranzakcie, tiez su tu rady, ze datovu konzistenciu ma drzat databaza, ale co ked vratenie penazi na ucet nakupujuceho je nejake XML volanie do banky. Cize sa to neda spravit ako nejaka databazova tranzakcia, ani to databaza nemoze riesit svojou konzistenciou. No, ono cele je to trochu slozitejsi problem, nez synchronizace - jde o to nejak nasimulovat distribuovanou transakci (predpokladam ze nemate k dispozici system s distribuovanymi transakcemi). Osobne bych to resil tak, ze bych zcela oddelil webove rozhrani a banovni operace. V operaci stornovani bych jen do zvlastni tabulky zapsal, ze se ma provest storno: INSERT INTO bank_operations (id_purchase, operation, time_planned, time_processed) VALUES (?,'storno',?, NULL) To by se samozrejme provedlo v jedne transakci s UPDATE ... SET storned = true; No a po dokonce by se spustil/naplanoval/probudil/upozornil mel nejaky task (treba pres JMS, nebo cokoliv) ktery by z te tabulky cetl a provadel ty jednotlive bankovni operace. Samozrejme, operace na storno by mela byt synchronizovana primo vbusiness logice, aby se neprovedla dvakrat; ale v kazdem pripade to chcipne v databazi na omezeni: UNIQUE(id_purchase, operation) To je vse jen takovy nastin co me napadlo. Vyhoda je, ze je v databazi zaznamenano co se v bance melo provest a co se provedlo a kdy (to je rozhodne dobry napad) a navic se neceka. Jiste, muze dojit k tomu ze banka operaci odmitne, ale takove pripady se daji resit postou (v podstate musi - stejne se bankovni operace neprovadeji v realnem case). -- Kamil Podlesak [EMAIL PROTECTED]
Re: equals, hashcode, permission
Je tam jeste nejaka chyba?Uz iba ta klasicka o porovnavani Stringov. Takze namiesto: if (( cp.getName == this.getName () ) cp.getActions () == this.getActions ()) ma byt if ( cp.getName().equals(this.getName()) cp.getActions () == this.getActions ()) return true;
Re: equals, hashcode, permission
Jasne, ale i v tom druhem pripade musi byt take equals, protoze getActions je taky jenom String, Nic jineho uz tam krome equalsa nullpointerexception neni? - Original Message - From: Richard Malaschitz To: Java Sent: Thursday, July 27, 2006 5:59 PM Subject: Re: equals, hashcode, permission Je tam jeste nejaka chyba?Uz iba ta klasicka o porovnavani Stringov. Takze namiesto: if (( cp.getName == this.getName () ) cp.getActions () == this.getActions ()) ma bytif ( cp.getName().equals(this.getName()) cp.getActions () == this.getActions ()) return true;
Re: equals, hashcode, permission
Java umožňuje u Stringů dělat tzv. internalizaci (metoda intern()), tzn. že pokud se má vytvořit String a String se stejným textem už existuje, vrátí ten původní. Při vytváření pomocí literálu se STring internalizuje vždy. Tzn. ve vašem případě při vytváření objektu b si Java zjistí, že už String s obsahem TEXT má a místro vytvoření nového objektu použije ten. Takže a i b jsou v tomto případě opravdu stejný objket a platí tedy a == b. Pokud byste to upravil např. naString a = TEXT;String b = xTEXT.substring(1); if ( a == b ) System.out.println ( a and b are the same. );už možná podmínka a == b splněna nebude.Filip Jirsák2006/7/27, Kamzik-II [EMAIL PROTECTED]: Jeste me trochu zarazi to equals... Protoze jsem zkousel napsat si program: String a = TEXT; String b = TEXT; if ( a == b ) System.out.println ( a and b are the same. ); A v pohode to proslo a funguvalo, takze jsem z toho trosku paf ;-) - Original Message - From: Kamzik-II To: Java Sent: Thursday, July 27, 2006 6:03 PM Subject: Re: equals, hashcode, permission Jasne, ale i v tom druhem pripade musi byt take equals, protoze getActions je taky jenom String, Nic jineho uz tam krome equalsa nullpointerexception neni? - Original Message - From: Richard Malaschitz To: Java Sent: Thursday, July 27, 2006 5:59 PM Subject: Re: equals, hashcode, permission Je tam jeste nejaka chyba?Uz iba ta klasicka o porovnavani Stringov. Takze namiesto: if (( cp.getName == this.getName () ) cp.getActions () == this.getActions ()) ma bytif ( cp.getName().equals(this.getName()) cp.getActions () == this.getActions ()) return true; -- Filip Jirsák[EMAIL PROTECTED]
Literatura
Práv si objednávám dnes zmiovanou knihu Effective Java, doporucily byste mi nkdo jet njakou jinou? Pedem íkám, e nemám zájem o knihu, kde je plka nebo více obsahu vnovaná gui (awt, swing, ...), nemám prost o gui vbec zájem. Poradí mi nkdo? - Original Message - From: Vladimir Bobes Tuzinsky To: Java Sent: Thursday, July 27, 2006 6:11 PM Subject: Re: equals, hashcode, permission to suvisi s tym, ze a aj b ukazuje na ten isty objekt. Je to vdaka String poolu. Ale to je opat jedna zo zakladnych veci, ktore sa daju nastudovat v beznej literature. Mam pocit, ze este jeden den pride na konferenciu tolko spamu ako dnes, tak sa z nej odhlasim... :( On 27/07/06, Kamzik-II [EMAIL PROTECTED] wrote: Jeste me trochu zarazi to equals... Protoze jsem zkousel napsat si program: String a = "TEXT"; String b = "TEXT"; if ( a == b ) System.out.println ( "a and b are the same." ); A v pohode to proslo a funguvalo, takze jsem z toho trosku paf ;-) - Original Message - From: Kamzik-II To: Java Sent: Thursday, July 27, 2006 6:03 PM Subject: Re: equals, hashcode, permission Jasne, ale i v tom druhem pripade musi byt take equals, protoze getActions je taky jenom String, Nic jineho uz tam krome equalsa nullpointerexception neni? - Original Message - From: Richard Malaschitz To: Java Sent: Thursday, July 27, 2006 5:59 PM Subject: Re: equals, hashcode, permission Je tam jeste nejaka chyba?Uz iba ta klasicka o porovnavani Stringov. Takze namiesto: if (( cp.getName == this.getName () ) cp.getActions () == this.getActions ()) ma bytif ( cp.getName().equals(this.getName()) cp.getActions () == this.getActions ()) return true;
Re: Literatura
Jo a jeste me nezajimaji ruzne frameworky, jako je treba spring, hibernate, atp... proste me zajima jenom non-gui java cast - Original Message - From: Kamzik-II To: Java Sent: Thursday, July 27, 2006 6:19 PM Subject: Literatura Práv si objednávám dnes zmiovanou knihu Effective Java, doporucily byste mi nkdo jet njakou jinou? Pedem íkám, e nemám zájem o knihu, kde je plka nebo více obsahu vnovaná gui (awt, swing, ...), nemám prost o gui vbec zájem. Poradí mi nkdo? - Original Message - From: Vladimir Bobes Tuzinsky To: Java Sent: Thursday, July 27, 2006 6:11 PM Subject: Re: equals, hashcode, permission to suvisi s tym, ze a aj b ukazuje na ten isty objekt. Je to vdaka String poolu. Ale to je opat jedna zo zakladnych veci, ktore sa daju nastudovat v beznej literature. Mam pocit, ze este jeden den pride na konferenciu tolko spamu ako dnes, tak sa z nej odhlasim... :( On 27/07/06, Kamzik-II [EMAIL PROTECTED] wrote: Jeste me trochu zarazi to equals... Protoze jsem zkousel napsat si program: String a = "TEXT"; String b = "TEXT"; if ( a == b ) System.out.println ( "a and b are the same." ); A v pohode to proslo a funguvalo, takze jsem z toho trosku paf ;-) - Original Message - From: Kamzik-II To: Java Sent: Thursday, July 27, 2006 6:03 PM Subject: Re: equals, hashcode, permission Jasne, ale i v tom druhem pripade musi byt take equals, protoze getActions je taky jenom String, Nic jineho uz tam krome equalsa nullpointerexception neni? - Original Message - From: Richard Malaschitz To: Java Sent: Thursday, July 27, 2006 5:59 PM Subject: Re: equals, hashcode, permission Je tam jeste nejaka chyba?Uz iba ta klasicka o porovnavani Stringov. Takze namiesto: if (( cp.getName == this.getName () ) cp.getActions () == this.getActions ()) ma bytif ( cp.getName().equals(this.getName()) cp.getActions () == this.getActions ()) return true;
