Case insensitive string maps

[solonovamax]

I think it would be nice if case insensitive string maps could be offered
so it would be a map of String to the different primitive types, e.g. CaseInsensitiveString2BooleanMap, CaseInsensitiveString2IntMap, etc.

[pburka]

Generally, one solves this by normalization. Convert all keys to uppercase or lowercase before using them in the map. Note that, in Java, strings cache their hash codes so it's constant time after the first use. If you were using a custom (case insensitive) hash, you'd lose that performance boost. Peter

…

On Thu, Dec 25, 2025, 6:43 PM solo ***@***.***> wrote: *solonovamax* created an issue (vigna/fastutil#376) <#376> I think it would be nice if case insensitive string maps could be offered so it would be a map of String to the different primitive types, e.g. CaseInsensitiveString2BooleanMap, CaseInsensitiveString2IntMap, etc. — Reply to this email directly, view it on GitHub <#376>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA6GRS3R2P6RTOMED3J754T4DRZD5AVCNFSM6AAAAACQAXOZJWVHI2DSMVQWIX3LMV43ASLTON2WKOZTG43DENBUHA4DENA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[solonovamax]

Generally, one solves this by normalization. Convert all keys to uppercase or lowercase before using them in the map. Note that, in Java, strings cache their hash codes so it's constant time after the first use. If you were using a custom (case insensitive) hash, you'd lose that performance boost.

hmm, actually yeah that's a good point.
I only made the issue because I thought of it while looking through ktor's code, where they have their own implementation of CaseInsensitiveMap which is used in a few places with some primitives which end up being boxed (not that ktor would be able to benefit from such a thing in fastutil anyways as it would need to be compatible with kotlin/multiplatform lol), and for some reason it did not cross my mind that that's what you'd do (even though if you'd asked me outside of this context that's what I would have done) (and, come to think of it, why do they even have a dedicated class for it rather than just doing that)

I guess one benefit of having a dedicated class for it is that you can preserve the original case of the string when it was added to the map (e.g. you are doing something like recording http headers where for some reason you may want the original case later, but generally it makes no difference), but idk if that's valuable enough to warrant its inclusion.

if desired, I can close the issue.

[imDaniX]

For case insensitive stuff, I'm using Custom "family" of maps/collections with a custom strategy:

public final class CaseInsensitive {
    private CaseInsensitive() { }
    
    private static final Hash.Strategy<String> CI_STRATEGY = new Hash.Strategy<>() {
        @Override
        public int hashCode(String str) {
            if (str == null) return -1;
            final int length = str.length();
            int result = 0;
            for (int i = 0; i < length; i++) {
                result = 31 * result + Character.toLowerCase(str.charAt(i));
            }
            return result;
        }

        @Override
        public boolean equals(String left, String right) {
            return left == null
                    ? right == null
                    : left.equalsIgnoreCase(right);
        }
    };

    public static @NotNull Hash.Strategy<String> strategy() {
        return CI_STRATEGY;
    }

    public static <$Value> @NotNull SortedMap<String, $Value> newLinkedMap() {
        return new Object2ObjectLinkedOpenCustomHashMap<>(CI_STRATEGY);
    }

    public static <$Value> @NotNull Map<String, $Value> newMap() {
        return new Object2ObjectOpenCustomHashMap<>(CI_STRATEGY);
    }

    public static @NotNull SortedSet<String> newLinkedSet() {
        return new ObjectLinkedOpenCustomHashSet<>(CI_STRATEGY);
    }

    public static @NotNull Set<String> newSet() {
        return new ObjectOpenCustomHashSet<>(CI_STRATEGY);
    }
}

(sorry for my weird generics $Value naming, I just like it being informative with no javadocs)
While it may have some downsides compared to some hypothetical string-"native" implementation, it does work well for me: for my cases, it usually is faster than the normalization, and it preserves the original case which I do need.