> I was looking at how the overriding of these two methods will help
the
> container . Because 1-2 years back when I coded the primary key
class with
> not very good implementation of hashcode or equals methods , I didnt
faced
> any problem. Infact no body was bothered about them in my team.
> What I will try to do now is to introduce some defects by doing
simple
> overriding of these methods and see what happens. As cedric pointed
out , I
> may get ObjectNotFoundException from container.
And weren't you VERY lucky!!
If you had implemented it Cedric's way, you would NOT have got the
exception at the container...... and then where would you be? Still
scratching your head I'll bet, wondering why you are getting
unpredicatable output from your code.
Exceptions are not thrown to be caught and hidden away from console
screens, they are there to tell you that somthing has gone wrong. A
runtime error such as the one that was thrown should definately not be
caught in the Bean...... once you get the exception at the container,
you watch the stack trace, trace it back to your code, and investigate
from there.....
Try not to think of an Exception on the console of the app server as
being BAD... think of it like the oil light in your car. You can stop,
add oil, and have many more happy miles of motoring -OR- you can drive
on and wait for the engine to blow. Let the exception come
through..... you need to know that things are gone wrong!!
-Enda.
>
> Ashwani
>
> ----- Original Message -----
> From: "Juan Pablo Lorandi" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, June 25, 2002 11:51 AM
> Subject: Re: hashcode and equals method
>
>
> 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.h
tm
> 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".
>
>
======================================================================
=====
> 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".
