2013-08-21 13 views
13

Czy istnieje alternatywa dla Guava Tables, która używa kluczy podstawowych zamiast typów ogólnych?Prymitywna alternatywa dla tabeli Guava

Chciałbym użyć prymitywów, aby uniknąć auto-boxingu spowodowanego użyciem numerów Javy i dodatkowych obiektów wejściowych utworzonych przez Java Maps.

Wyprodukowałem własną podstawową tabelę LongLongObject za pomocą Trove TLongObjectMap, ale wolałbym korzystać ze standardowej biblioteki, jeśli jest dostępna.

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; 
    } 
} 
+5

Mapy, listy, zestawy w Javie działają na obiektach. W końcu boks się wydarzy, a ty z nich skorzystasz. IMHO nie jest warte walki z tym. Jeśli potrzebujesz prostszego interfejsu, zawsze możesz go wdrożyć z wzorcem delegowania, takim jak wklejony. – allprog

+2

Czy profilowałeś swoją aplikację? Możesz być w porządku z Tabelami Guava pomimo boksów i obiektów wejściowych. –

+2

IMHO to brzmi jak wczesna optymalizacja. Rozumiem, że chcesz, aby aplikacja działała tak szybko, jak to możliwe. Ale aby autoboxing zaczął byc wąskim gardłem, potrzebowałeś obciążenia '> 10^n' operacji na sekundę, z' n' w zależności od twojego konkretnego problemu, chociaż w ogóle 'n> 3'. Jesteś pewien, że to twoja sprawa? –

Odpowiedz

2

Niezupełnie. Problem polega na tym, że takie wdrożenia nie są z założenia ogólne (z definicji) i trzeba by je zdefiniować jeden po drugim. Oznacza to znaczące powtórzenia i potencjalnie wiele możliwych permutacji zbierania.

To powiedziawszy, inne języki pozwalają na to, powodując, że kompilator generuje kod dla instancji kolekcji z typem T zamiast używać type erasure, ale to nie jest kierunek, w którym poszła java.

Fakt, że można stosować warianty z auto-pudełkami, takie jak Long lub Integer, przy istniejącej kolekcji jest wystarczająco dobry w większości przypadków, ponieważ obciążenie jest stosunkowo niskie. Również projektanci standardowej biblioteki wolą raczej zachować ją szczupłą niż zanieczyszczać ją dodatkowymi niestandardowymi wariantami.