Primitive alternative to Guava Table

Question

Is there an alternative to Guava Tables that uses primitives, instead of generic types, as the keys?

I would like to use primitives to avoid the auto-boxing caused by using Java Numbers and the additional entry objects created by Java Maps.

I've rolled my own basic LongLongObjectTable using Trove TLongObjectMap, but would prefer to use a standard library if one is available.

private static class LongLongObjectTable<T> {
    private final TLongObjectMap<TLongObjectMap<T>> backingMap = new TLongObjectHashMap<>();

    T get(final long rowKey, final long columnKey) {
        final TLongObjectMap<T> map = this.backingMap.get(rowKey);
        if (map == null) {
            return null;
        }
        return map.get(columnKey);
    }

    void put(final long rowKey, final long columnKey, final T value) {
        TLongObjectMap<T> map = this.backingMap.get(rowKey);
        if (map == null) {
            map = new TLongObjectHashMap<>();
            this.backingMap.put(rowKey, map);
        }
        map.put(columnKey, value);
    }

    Collection<T> values() {
        final List<T> values = new ArrayList<T>();
        for (final TLongObjectMap<T> map : this.backingMap.valueCollection()) {
            values.addAll(map.valueCollection());
        }
        return values;
    }
}

Radom

Maps, Lists, Sets in Java operate on objects. In the end the boxing will happen anyway of you utilize them. IMHO it's not worth fighting against it. If you need a simpler interface, you can always implement it with a delegation pattern like what you pasted. – Bye

Have you profiled your application? You might be just fine with Guava's Tables despite the boxing and entry objects. – Coquelicot

IMHO this sounds like early optimization. I understand you want to make your app run as fast as possible. But for autoboxing to start being a bottle-neck, you'd need a load of >10^n operations per second, with n depending on your specific problem, though in general n>3. Are you sure this is your case? – Kra

@Magnamag It might have nothing to do with operations per second, but instead with memory. – Lexie

You're probably better off with koloboke or fastutils than Trove, they tend to be more memory efficient and faster. java-performance.info/… – Sebaceous

You could always contribute to Trove (or the other projects Straw mentions) with a primitive Table implementation. – Caudill

Answer 1

Not really. The problem is that such implementations are imminently not generic (by definition) and would need to be defined one by one. This means significant repetition and potentially a lot of possible collection permutations.

That said, other languages do allow this by making the compiler generate code for instances of a collection with type T rather than use type erasure, but that is not the direction java went.

The fact that you can use auto-boxed variants like Long or Integer on existing collection is good enough for the vast majority of cases, as the overhead is relatively low. Also, the designers of the standard library probably prefer to keep it slim rather than pollute it with additional custom variants.

Trousseau