Miles Sabin wrote:
>
> Apart from anything else, hashCodes are ints, so there are at
> most 2^32 distinct ones. A 64 bit implementation could support
> more that 2^32 objects, in which case there'd have to be some collisions.
This is not quite correct; only 21 bits are used for the HashCode.
--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 ove
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 di
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 r
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 wa
> 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 sug
On Tue, 4 Jul 2000, Miles Sabin wrote:
> Mo DeJong wrote,
> > There seems to be a really serious bug in the
> > System.identityHashCode() method in all > JDK 1.2 releases
> > derived from Sun code. The problem only shows up in "high
> > load" situations. Basically, two different Java objects o
On 4 Jul 2000, Juergen Kreileder wrote:
> It's no bug, the behavior is absolutely legal.
...
> The implementation of Object.hashCode() was changed in 1.2 for
> security reasons.
...
> It's no bug.
>
> Mo> The final option would be to write my own UID() method that
> Mo> would try to
On Mon, 3 Jul 2000, Christopher Smith wrote:
> --On Monday, July 03, 2000 4:24 PM -0700 Mo DeJong <[EMAIL PROTECTED]>
> wrote:
> > Exception in thread "main" tcl.lang.TclRuntimeError:
> >
> > (find) table entry "SomeObject.1512497281" mapped to an invalid
> > entry,
>
> I'm not famili
--On Tuesday, July 04, 2000 1:37 AM +0100 Miles Sabin
<[EMAIL PROTECTED]> wrote:
> Mo DeJong wrote,
>> There seems to be a really serious bug in the
>> System.identityHashCode() method in all > JDK 1.2 releases
>> derived from Sun code. The problem only shows up in "high
>> load" situations. Basi
> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes:
Mo> There seems to be a really serious bug in the
Mo> System.identityHashCode() method in all > JDK 1.2 releases
Mo> derived from Sun code. The problem only shows up in "high
Mo> load" situations. Basically, two different Java ob
--On Monday, July 03, 2000 4:24 PM -0700 Mo DeJong <[EMAIL PROTECTED]>
wrote:
> Exception in thread "main" tcl.lang.TclRuntimeError:
>
> (find) table entry "SomeObject.1512497281" mapped to an invalid
> entry,
I'm not familiar with the Jacl code base, but this error does not jibe with
Mo DeJong wrote,
> There seems to be a really serious bug in the
> System.identityHashCode() method in all > JDK 1.2 releases
> derived from Sun code. The problem only shows up in "high
> load" situations. Basically, two different Java objects of
> the same class can return the exact same uniq
13 matches
Mail list logo
