First, they're not my articles. I just compiled for all the people out there who are google-challenged ;-)
Altough I'm not quite sure how may I have offended Cedric, it certainly wasn't my aim. I was under the impression that we were having an intelligent debate. Maybe passionate, but certainly not injuriating. Whomever I might have offended, my deepest heartfelt apology. On a different note, as you point out, if I were desinging a container I would aim differently. I think that permeates my previous mail. Also, altough coding differently equals() and hashCode() might help the container and improve speed, it isn't strongly related to your EJB executing normally(except some very foul equals() imp.). I have real life proof now, _you_ are. In fact nobody on your team has even bothered about coding them "correctly" in 2 years; except maybe now when you'll get down and fix something that works. Well, I don't see nothing bad in reassuring ;-) I assume when you say you'll introduce some defects to see if you get a lot of ObjectNotFoundException's you mean you'll try to test Cedric's assertion empirically. I hope you share any insight you obtain with the list. Regards, 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 9:13 AM > To: [EMAIL PROTECTED] > Subject: Re: hashcode and equals method > > > hi, > Juan I have gone through your articles. They are quite > informative. But why are you making such remarks toward > Cedric. Obviously if you were to develop or design some > container you will also think or try to ans from that > perspective. I know Cedric also contributed code for > hashcode and equals method to this list some time back. 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. > > 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/r > untime.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". > > ============================================================== > ============= > 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".
