 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / November 2007large Object as map key
Hi all, i am using a large object as key in hashmap without implementing the hashCode() and equal(Object obj) methods. Large object means class having lots of data. any performance problem? Best Regards, ronan Hi, rony.john@gmail.com schrieb: > Hi all, > i am using a large object as key in hashmap without > implementing the hashCode() and equal(Object obj) methods. Large > object means class having lots of data. > > any performance problem? No performance problem. Ciao, Ingo PS: But a semantical problem, of course. Note that equals and hashCode must be implemented when you want to use such an object as kay in a HashMap. > Hi, > [quoted text clipped - 14 lines] > PS: But a semantical problem, of course. Note that equals and hashCode > must be implemented when you want to use such an object as kay in a HashMap. thanks very much for your quick reply. On Nov 23, 4:00 pm, rony.j...@gmail.com wrote: > > Hi, > [quoted text clipped - 16 lines] > > thanks very much for your quick reply. there is no problem but you must overide your equals ans hashcode method > On Nov 23, 4:00 pm, rony.j...@gmail.com wrote: >> > > i am using a large object as key in hashmap without [quoted text clipped - 5 lines] > there is no problem but you must overide your equals ans hashcode > method Really, "must"? If his class is designed such, that every instance is per definition unique (unequal to every other instance), then overriding Object's hashCode() and equals() shouldn't be necessary. Well, thats true. But if he loses the reference for a key ! there is no way to retrieve the value against it !! Its risky but implementation Dependant. As for the question, since you are making use of the Objects equal method for comparing objects which is bit to bit comparison, instinctively it tells that there might be performance impact. If you have overridden the equals and hashcode methods it would have been simpler, then it may not dependant on the object size but just ur logic in those methods. Regards, Ravi On Nov 23, 5:09 pm, Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at> wrote: > > On Nov 23, 4:00 pm, rony.j...@gmail.com wrote: > >> > > i am using a large object as key in hashmap without [quoted text clipped - 9 lines] > per definition unique (unequal to every other instance), then overriding > Object's hashCode() and equals() shouldn't be necessary. >> > there is no problem but you must overide your equals ans hashcode >> > method [quoted text clipped - 4 lines] > no way to retrieve the value against it !! Its risky but > implementation Dependant. Why not? You can easily (and without any risk) iterate the HashMap, then you see all the elements inside, so nothing is really lost. > As for the question, since you are making > use of the Objects equal method for comparing objects which is bit to > bit comparison, I don't think so: Object's equal() does only "compare" the Reference itself; nothing of the data inside the object's instance is examined! PS: Quoting rearranged. Please respond *below* the parts that you respond to. A: because the answer should follow the question. Q: why? :-) >>>> there is no problem but you must overide your equals ans hashcode >>>> method [quoted text clipped - 13 lines] > I don't think so: Object's equal() does only "compare" the Reference > itself; nothing of the data inside the object's instance is examined! It is actually quite common to use reference comparison in Map keys, i.e., not to override equals(), You only override equals() when a class's notion of equality requires value comparison. Then, of course, you must also override hashCode() to be consistent with equals(). Overriding equals(), like just about any rule of thumb, is not a law that you must *always* follow. It's something you do if and only if the semantics of your class need it.  SignatureLew Ravi schreef: Please do not top-post. > Well, thats true. But if he loses the reference for a key ! there is > no way to retrieve the value against it !! Um, what about map.keyset()? > Its risky but > implementation Dependant. As for the question, since you are making > use of the Objects equal method for comparing objects which is bit to > bit comparison, instinctively it tells that there might be performance > impact. No, it compares pointers. H. > On Nov 23, 5:09 pm, Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at> > wrote: [quoted text clipped - 10 lines] >> per definition unique (unequal to every other instance), then overriding >> Object's hashCode() and equals() shouldn't be necessary. SignatureHendrik Maryns http://tcl.sfs.uni-tuebingen.de/~hendrik/ ================== http://aouw.org Ask smart questions, get good answers: http://www.catb.org/~esr/faqs/smart-questions.html > Hi, > [quoted text clipped - 14 lines] > must be implemented when you want to use such an object as kay in a > HashMap. You need to override the equals and hashCode inherited from Object if, and only if, two distinct instances of the class can be logically equal. If equality for the class is equivalent to identity then the Object equals and hashCode methods do exactly the right thing. Patricia Hi, Patricia Shanahan schrieb: > You need to override the equals and hashCode inherited from Object if, > and only if, two distinct instances of the class can be logically equal. > > If equality for the class is equivalent to identity then the Object > equals and hashCode methods do exactly the right thing. Upps, you are right - perhaps I misinterpreted ronys question. Ciao, Ingo > i am using a large object as key in hashmap without >implementing the hashCode() and equal(Object obj) methods. Large >object means class having lots of data. >any performance problem? No problem. Your object DOES have hashCode() and equals(Object) methods. They're the ones you're inheriting from Object, and they'll just check object identity, not logical equality. -- Mark Rafn dagon@dagon.net <http://www.dagon.net/> > i am using a large object as key in hashmap without >implementing the hashCode() and equal(Object obj) methods. Large >object means class having lots of data. > >any performance problem? What will happen is the hashCode will be the address of the object. To lookup you will actually have the original big Object, not just a clone of it. Default equals just compares addresses. So this will be very fast, but perhaps not that useful. You might as well just had a direct link from the Object to the additional information rather than fooling around with a HashMap. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com > What will happen is the hashCode will be the address of the object. Strictly speaking, this isn't true. The Javadocs speak of a hash that is based on some sort of "address" of an object, but the semantics of hashCode() and an address are completely unrelated. Bear in mind that an address of an object changes throughout its lifetime, and is represented in a JVM by a combination of data that together typically take up more than 32 bits. In particular, one could not take a hashCode() of an object and somehow coerce it into working as a pointer to the object. Also, it is possible for objects to share a hashCode(). All this without taking into consideration the plethora of classes that override hashCode() to use a different algorithm altogether. SignatureLew Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.