2013-08-21 30 views
13

是否有替代Guava Tables使用原始類型而不是泛型類型作爲關鍵字?番石榴的原始替代表

我想使用原語來避免使用Java Numbers和由Java Maps創建的其他條目對象造成的自動裝箱。

我已經使用Trove TLongObjectMap推出了我自己的基本LongLongObjectTable,但是如果有可用的話,我寧願使用標準庫。

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

Java中的地圖,列表,集合對對象進行操作。最後,無論如何,拳擊將發生你利用他們。恕我直言,這是不值得對付它。如果您需要更簡單的界面,您可以始終使用您粘貼的代理模式來實施它。 – allprog

+2

你是否分析了你的應用程序?儘管拳擊和進入的對象,你可能會用番石榴的表。 –

+2

恕我直言,這聽起來像是早期的優化。我知道你想盡可能快地運行你的應用程序。但是爲了讓自動裝箱開始成爲一個瓶頸,你需要每秒鐘處理大於10^n次的操作,'n'取決於你的具體問題,儘管一般來說'n> 3'。你確定這是你的情況嗎? –

回答

2

不是。問題是這樣的實現不是通用的(根據定義),需要逐個定義。這意味着重大的重複和潛在的很多可能的收集排列。也就是說,其他語言通過讓編譯器爲類型爲T的集合的實例生成代碼而不是使用type erasure來實現這一點,但這不是java去的方向。

事實上,您可以在現有集合上使用像Long或Integer這樣的自動裝箱變體,這對於絕大多數情況來說已經足夠了,因爲開銷相對較低。此外,標準庫的設計者可能更喜歡保持苗條而不是用額外的定製變體污染它。