Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Stargrasper]

Also, String objects constructed with new are considered different according to the == operator, while String objects constructed like primitives with the same literal are considered identical.

Hmm, make sure you are dealing with 'Strings' and not 'strings'.
Chances are that Java is trying to be a little more c#, thus making strings act more like a primitive, but instead of adding functionality to a class, it now has a new thing called a 'string', and that can be used as a String, but acts differently.
So polymorphism is fucking you up.

I would look for this in the docs myself, but too busy making the grass turn red when you spill blood onto it.

There's no such thing as a string in Java.  You only have String.

[LoSboccacc]

That's a common pitfall. Remember that java is a single dispatch language. Beware of casting stuff around, if you have extended class with overloaded methods

[Darvi]

I heard somewhere that string comparisons in Java using == would still work exactly the same way, i.e. it checks the memory position, but the way identical strings get handled in a way that makes it so that it works anyway.

[Stargrasper]

I heard somewhere that string comparisons in Java using == would still work exactly the same way, i.e. it checks the memory position, but the way identical strings get handled in a way that makes it so that it works anyway.

Basically.  My research demonstrated you can use == for comparison if you know what you're doing, that is, where it will and will not work.  I still would never do it in my own code, but that's just because I was trained not to...

[Mego]

My speedrunning instincts are kicking in and mixing with my Bay12 instincts.

How can we weaponize Java's inconsistency to make things run faster?

[Max White]

Spoiler: TREES!!! (click to show/hide)

[Stargrasper]

Spoiler: TREES!!! (click to show/hide)

Woot!

My speedrunning instincts are kicking in and mixing with my Bay12 instincts.

How can we weaponize Java's inconsistency to make things run faster?

We can't weaponize it to make things faster...Java's one of the slowest languages I know.  Things you plug into it automatically get slower by virtue of being run through the JVM.  We weaponize it by running our targets through the JVM and everything is faster by comparison.

More seriously, please don't derail this thread.  We've put too much work into it.

Stargrasper's current current goal: Decide if String HashCodes are Really Unique.  I'm thinking the answer is actually no.

[Mego]

Well, seeing as how "foo" on my system has the same hashcode as "foo" on your system, I'm thinking no. If I knew anything about crypto, I could help figure out the hashing algorithm.

[Max White]

So basically java keeps it's strings in a hash map, and uses the char[] itself as the key... Weird.

[Stargrasper]

Well, seeing as how "foo" on my system has the same hashcode as "foo" on your system, I'm thinking no. If I knew anything about crypto, I could help figure out the hashing algorithm.

I have the actual source in front of me.  I just looked up String's hashCode() method.

String hashes are calculated by the following equation

Code: [Select]

s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]
Where s is the character array containing the values of the String and n is the length of the String.

I'm not looking for a counter example, but I'm pretty sure it's possible for two different strings to hash to the same value.  I do vaguely remember being told never to hash a String, but I can't quite remember why.  I think it may have been because they weren't necessarily unique.

Want me to detail exactly how Java does this for you?

[Mego]

Is that ^ for exponentiation or XOR?

[Stargrasper]

Is that ^ for exponentiation or XOR?

Exponentiation.  Here's the actual function from the java.lang.String source.

Code: [Select]

    /**
     * Returns a hash code for this string. The hash code for a
     * <code>String</code> object is computed as
     * <blockquote><pre>
     * s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]
     * </pre></blockquote>
     * using <code>int</code> arithmetic, where <code>s[i]</code> is the
     * <i>i</i>th character of the string, <code>n</code> is the length of
     * the string, and <code>^</code> indicates exponentiation.
     * (The hash value of the empty string is zero.)
     *
     * @return  a hash code value for this object.
     */
    public int hashCode() {
        int h = hash;
        if (h == 0 && count > 0) {
            int off = offset;
            char val[] = value;
            int len = count;

            for (int i = 0; i < len; i++) {
                h = 31*h + val[off++];
            }
            hash = h;
        }
        return h;
    }


[Mego]

That's an interesting method of calculating that summation. Remind me to be smart like that instead of using Math.pow. Regardless, now our job is to figure out two different Strings with identical hashcodes.

[Max White]

Well he may not be very bright at all, not really doing much other than standing there looking pretty, yet behold!

Spoiler: NPC! (click to show/hide)

[MaximumZero]

Aww, he looks so happy!