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
