Great question. Again, looking at things from a diferent perspective
than Cedric(he works for bea, they make Weblogic, I'm just a poor humble
argentinian coder living in the exile), a good server might take care of
this for you. It would only need to use introspection mechanisms that
are part of the JRE, I'd like to presume, but again, I don't build app
servers, so I can afford a little ignorance on the subject.
Well, the idea behind J2EE, from a developer point of view, is to take
away complexity from the business logic coder. You should stick to the
spec, not try to make the AppServer programmer life easy. If you can,
well, that's superb. First things first, check out the javadoc for
java.lang.Object; it defines the contract equals() and hashcode() should
implement. A valid, yet very inefficient hashcode implementation would
be:
public int hashCode() {
return 1;
}
More info on the contract is also available on the javadoc for
java.util.Hashtable.
First thing about equals, as Cedric points out, is to get it right.
Apart from java.lang.Object, you should also keep in mind the extra
requirements made by the Colections framework(java.util.
Collection/Set/List/Map). Nevertheless, the EJB 2.0 spec doesn't
explicitly impose any other requirement on the equals() implementation
within the PK class. Hence, it is a grey area, where no opinion stands
with enough weight by itself. One could argue(but would be pushing it),
that since the EJB spec doesn't specify any behavior from equals a
container that relies on equals() being correctly implemented is a very
bad(a.k.a. naughty) container. Of course, this assertion doesn't make
much sense.
To the juicy part.
Links:
Hashtable on equals and hashCode:
http://www.javaworld.com/javaqa/2002-06/01-qa-0621-hashtable.html
Not all equals are equal(brings up Strongly-Typed equals() ):
http://www.cuj.com/java/articles/a19.htm?topic=java
Runtime Exceptions:
http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.htm
l
On other note, having repeatedly being asked questions by people that
claim that they don't find any information available on the internet on
these subjects has me particulary puzzled. I'm truly beginning to wonder
if one must be of western extraction to master the use of google.
Google Help:
http://www.google.com/help/
My 2c,
Juan Pablo Lorandi
Chief Software Architect
Code Foundry Ltd.
[EMAIL PROTECTED]
Barberstown, Straffan, Co. Kildare, Ireland.
Tel: +353-1-6012050 Fax: +353-1-6012051
Mobile: +353-86-2157900
www.codefoundry.com
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]] On Behalf Of Ashwani Kalra
> Sent: Tuesday, June 25, 2002 6:12 AM
> To: [EMAIL PROTECTED]
> Subject: Re: hashcode and equals method
>
>
> Why dont container just compare the public fields of my
> Primary key class to search for entity. Why it relies on
> equals and hashcode. ??
> ----- Original Message -----
> From: "Cedric Beust" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, June 25, 2002 10:28 AM
> Subject: Re: hashcode and equals method
>
>
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]] On Behalf Of Ashwani Kalra
>
> > hi,
> > I have few questions on overriding the hashcode and equals
> method in
> > primary key class
> >
> > 1. If I dont implement these methods properly then what are the
> > problems I can face.
>
> It depends how bad you implement them :-)
>
> It is very important to get equals() right. It is easy to
> get it right, it is harder to get it efficient. To get it
> right, you simply need to respect the rules given in the Javadoc at
>
> http://java.sun.com/j2se/1.3/docs/api/java/lang/Object.html#eq
> uals(java.
> lang.Object)
>
> If you fail to get it right, your EJB container will probably
> reward you with numerous ObjectNotFoundException as it keeps
> failing to find your Entity beans through their primary keys.
>
> To get it efficient, you can refer to the emails that Juan
> and I just exchanged, or some longer threads that have taken
> place on theserverside.
>
> hashCode() is a little different since it only affects
> performance. Basically, the poorer your hash method is, the
> more collisions will occur when the container is storing the
> primary keys in its internal structure. The end result is
> probably longer cache access and other bad consequences (this
> is implementation-dependent). Same remark as above, there is
> plenty of literature on the subject, both from an EJB
> perspective, or more generally, on perfect hash functions.
>
> A rule of thumb: xoring (^ in Java) the respective
> hashCodes() of your primkey-fields usually yields a decent
> hash function. It doesn't hurt to experiment, though, you
> sometimes get very interesting results when you start
> investigating how your hash maps get filled.
>
> > 2. What is the best way to implement them.
> > 3. Do I always need to be careful or can I be liberal
> > in certain applications
> > 4 I have read that any implementation what ever is not foolproof.
>
> I hope to have given you enough information to answer these
> questions. I would definitely recommend leaving the
> generation of these functions to tools (well, good ones :-)).
>
> --
> C�dric
>
> =========================
> To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the body of the message "signoff EJB-INTEREST".
> For general help, send email to [EMAIL PROTECTED] and
> include in the body of the message "help".
>
> ==============================================================
> =============
> To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the body of the message "signoff EJB-INTEREST".
> For general help, send email to [EMAIL PROTECTED] and
> include in the body of the message "help".
>
==========================================================================To
unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
