Re: Serious bug in System.identityHashCode() found.
On Mon, 3 Jul 2000, Christopher Smith wrote: > > I don't get it. That was the whole point of adding the > > System.identityHashCode() method to 1.1. It was designed > > to return a UID in the case that a class overloaded > > the hashCode() method. Now folks seem to be saying "oh, > > yeah that was changed for 1.2". Changed to what? > > How would you suggest I generate a UID for two > > different object of the same class that return > > the exact same hash code? I can't get the memory > > location to implement my own UID method. > > Nope, the whole point of System.identityHashCode() was added so that == had > equivalent operators to Object.equals(Object). Essentially it allowed you to > create an identity hash table. If they had ment it to be a uid they would > have called it Object.getUid(). ;-) Humm, I am not sure if we are saying the same thing with different words. The System.identityHashCode() is not the equivalent of == in JDK 1.2. In JDK 1.1 it worked that way but now I am not sure what it is the equivalent of. It is most certainly not the .equals() method, the error example I posted showed that the two objects that mapped to the same hash would return false from a equals() comparison. My example also shows that identityHashCode() is not the equivalent of ==, the == test for two objects that hash to the same value returned false. What exactly do you mean when you say "identity hash table"? What would such a table do for you? > They didn't change the API. The docs have been the same for quite some time. > They did fix a conflict in the spec that said the following: Yes they did. The API does not work the same way it did in JDK 1.1. > Standard hashtables are based on Object.equals() and as such deal with the > hashCode collision issue. So, if you just use a standard Hashtable (or Set > depending on your needs), make sure you're using identityHashCode() and > =='s, then collisions will be dealt with for you. I am using a "standard hashtable". I need to map a UID string to a single Object, without a UID provided by the identityHashCode(), I am going to have a hard time doing that. Mo DeJong Red Hat Inc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: IBM 1.3 full release
I posted a report to IBM reporting the problem, I've got the response they forwarded the report to the webmaster :-<, may be I will ever get to a download :-) cu patrick p.s. I will check the links again later, may be there was just a server down, may be they us MS servers :-) Julio Cesar Aguilar Cabrera wrote: > > > Some of u managed to download the packages?? > > I did download the RPM package (27+Mb) without a problem. > I installed it but had time for nothing else. > > -- > Julio Cesar Aguilar Cabrera > [EMAIL PROTECTED] > Laboratorio Nacional de Informatica Avanzada > Xalapa, Veracruz, Mexico. > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- - Save software competition, use Linux and Java! mailto:[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Serious bug in System.identityHashCode() found.
On Tue, 4 Jul 2000, Diego Pons wrote: > Mo DeJong wrote: > > > I am using a "standard hashtable". I need to map a UID string to a > > single Object, without a UID provided by the identityHashCode(), > > I am going to have a hard time doing that. > > > > Am I missing the point? Hash codes (the result of a hash function) need not be > > different for different entities, hence the bucket concept. My reading the docs seemed to indicate the the System.identityHashCode() method would return a unique id for every object. That seemed to work in JDK 1.1 but in JDK 1.2 is no longer works. I guess I will just have to come up with a new implementation. Lets let this thread RIP, sorry for wasting everybody's time. Mo DeJong Red Hat Inc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Serious bug in System.identityHashCode() found.
Mo DeJong wrote: > I am using a "standard hashtable". I need to map a UID string to a > single Object, without a UID provided by the identityHashCode(), > I am going to have a hard time doing that. > Am I missing the point? Hash codes (the result of a hash function) need not be different for different entities, hence the bucket concept. -- Diego Pons Pharos Consulting LLC http://www.wenet.net/~dponsLos Angeles, CA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: THEY WORK AGAIN!!!
Ohh the links work now I guess they just had a server crash cu patrick Patrick Ohnewein wrote: > > I posted a report to IBM reporting the problem, I've got the response > they forwarded the report to the webmaster :-<, may be I will ever get > to a download :-) > > cu patrick > > p.s. I will check the links again later, may be there was just a server > down, may be they us MS servers :-) > > Julio Cesar Aguilar Cabrera wrote: > > > > > Some of u managed to download the packages?? > > > > I did download the RPM package (27+Mb) without a problem. > > I installed it but had time for nothing else. > > > > -- > > Julio Cesar Aguilar Cabrera > > [EMAIL PROTECTED] > > Laboratorio Nacional de Informatica Avanzada > > Xalapa, Veracruz, Mexico. > > > > -- > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- > - > Save software competition, use Linux and Java! > mailto:[EMAIL PROTECTED] > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- - Save software competition, use Linux and Java! mailto:[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Serious bug in System.identityHashCode() found.
--On Monday, July 03, 2000 11:58 PM -0700 Mo DeJong <[EMAIL PROTECTED]> wrote: > On Mon, 3 Jul 2000, Christopher Smith wrote: >> > I don't get it. That was the whole point of adding the >> > System.identityHashCode() method to 1.1. It was designed >> > to return a UID in the case that a class overloaded >> > the hashCode() method. Now folks seem to be saying "oh, >> > yeah that was changed for 1.2". Changed to what? >> > How would you suggest I generate a UID for two >> > different object of the same class that return >> > the exact same hash code? I can't get the memory >> > location to implement my own UID method. >> Nope, the whole point of System.identityHashCode() was added so that == >> had equivalent operators to Object.equals(Object). Essentially it >> allowed you to create an identity hash table. If they had ment it to be >> a uid they would have called it Object.getUid(). ;-) > > Humm, I am not sure if we are saying the same thing with different words. > The System.identityHashCode() is not the equivalent of == in JDK 1.2. In Nor should it be. Why bother creating a new method for doing something you can already do with the '==' operator? > JDK 1.1 it worked that way but now I am not sure what it is the > equivalent of. It is most certainly not the .equals() method, the > error example I posted showed that the two objects that mapped > to the same hash would return false from a equals() comparison. Perhaps I was not clear enough: System.identityHashCode() is to "==" as Object.hashCode() is to Object.equals(Object). Does that make more sense? > My example also shows that identityHashCode() is not the equivalent of ==, > the == test for two objects that hash to the same value returned false. > What exactly do you mean when you say "identity hash table"? What > would such a table do for you? That would give me a hash table where the key is the actual instance of the object itself rather than some concept of the value of the key. Such that (forgive the fact that this is 100% syntactically correct, I think it gets the idea across): KeyClass keyA = new KeyClass(); KeyClass keyB; KeyClass keyC; keyC = keyA.clone(); //assume for KeyClass a.equals(a.clone()) //is always true keyB = keyA; identityHash.put(keyC, "testC"); identityHash.put(keyB, "testB"); identityHash.put(keyA, "testA"); System.out.println(identityHash.get(keyA)); System.out.println(identityHash.get(keyB)); System.out.println(identityHash.get(keyC)); Should print out: testA testA testC >> They didn't change the API. The docs have been the same for quite some >> time. They did fix a conflict in the spec that said the following: > Yes they did. The API does not work the same way it did in JDK 1.1. They changed the behavior, not the API. There is a difference. The specification is VERY clear that while the VM will make all resonable efforts to avoid duplicate values of System.identityHashCode(Object), it makes no guaruntees. One should expect behavior to be different from one JDK to the next. Indeed, one should be prepared for behavior to be different from one VM to the next, so long as they're consistent with the documentation, it's not a change in the API. >> Standard hashtables are based on Object.equals() and as such deal with >> the hashCode collision issue. So, if you just use a standard Hashtable >> (or Set depending on your needs), make sure you're using >> identityHashCode() and =='s, then collisions will be dealt with for you. > I am using a "standard hashtable". I need to map a UID string to a > single Object, without a UID provided by the identityHashCode(), > I am going to have a hard time doing that. Actually, it doesn't have to be hard at all. Just create your own UID's. I do this all the time. --Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
hardware opengl success
Slightly off topic, but I was able to get a opengl card to work under linux and call it successfully from Java. This took about 1.5 days of configuring, between Xfree86 4 and the particular card. The result is dramatically faster for textured renders. Particulars are: RH6.2, added Xfree86 4.0.0 Nvidia Geforce2 chip (Elsa card), using their closed-source driver (an expert told me this is the current fastest card for my application) Calling thru the latest GL4Java, from several jdks including the latest 1.3. Java Swingset and such still run fine but this card does not speed up java2d significantly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
