@GwtCompatible public final class Tables extends Object
Table
.
See the Guava User Guide article on
Tables
.
Modifier and Type | Method and Description |
---|---|
static <R,C,V> Table.Cell<R,C,V> |
immutableCell(R rowKey,
C columnKey,
V value)
Returns an immutable cell with the specified row key, column key, and
value.
|
static <R,C,V> Table<R,C,V> |
newCustomTable(Map<R,Map<C,V>> backingMap,
Supplier<? extends Map<C,V>> factory)
Creates a table that uses the specified backing map and factory.
|
static <R,C,V> Table<R,C,V> |
synchronizedTable(Table<R,C,V> table)
Returns a synchronized (thread-safe) table backed by the specified table.
|
static <R,C,V1,V2> |
transformValues(Table<R,C,V1> fromTable,
Function<? super V1,V2> function)
Returns a view of a table where each value is transformed by a function.
|
static <R,C,V> Table<C,R,V> |
transpose(Table<R,C,V> table)
Creates a transposed view of a given table that flips its row and column
keys.
|
static <R,C,V> RowSortedTable<R,C,V> |
unmodifiableRowSortedTable(RowSortedTable<R,? extends C,? extends V> table)
Returns an unmodifiable view of the specified row-sorted table.
|
static <R,C,V> Table<R,C,V> |
unmodifiableTable(Table<? extends R,? extends C,? extends V> table)
Returns an unmodifiable view of the specified table.
|
public static <R,C,V> Table.Cell<R,C,V> immutableCell(@Nullable R rowKey, @Nullable C columnKey, @Nullable V value)
The returned cell is serializable.
rowKey
- the row key to be associated with the returned cellcolumnKey
- the column key to be associated with the returned cellvalue
- the value to be associated with the returned cellpublic static <R,C,V> Table<C,R,V> transpose(Table<R,C,V> table)
get(columnKey, rowKey)
on the
generated table always returns the same value as calling get(rowKey, columnKey)
on the original table. Updating the original table
changes the contents of the transposed table and vice versa.
The returned table supports update operations as long as the input table
supports the analogous operation with swapped rows and columns. For
example, in a HashBasedTable
instance, rowKeySet().iterator()
supports remove()
but columnKeySet().iterator()
doesn't. With a transposed HashBasedTable
, it's the other way around.
@Beta public static <R,C,V> Table<R,C,V> newCustomTable(Map<R,Map<C,V>> backingMap, Supplier<? extends Map<C,V>> factory)
Map
classes.
The factory
-generated and backingMap
classes determine
the table iteration order. However, the table's row()
method
returns instances of a different class than factory.get()
does.
Call this method only when the simpler factory methods in classes like
HashBasedTable
and TreeBasedTable
won't suffice.
The views returned by the Table
methods Table.column(C)
,
Table.columnKeySet()
, and Table.columnMap()
have iterators that
don't support remove()
. Otherwise, all optional operations are
supported. Null row keys, columns keys, and values are not supported.
Lookups by row key are often faster than lookups by column key, because
the data is stored in a Map<R, Map<C, V>>
. A method call like
column(columnKey).get(rowKey)
still runs quickly, since the row key
is provided. However, column(columnKey).size()
takes longer, since
an iteration across all row keys occurs.
Note that this implementation is not synchronized. If multiple threads access this table concurrently and one of the threads modifies the table, it must be synchronized externally.
The table is serializable if backingMap
, factory
, the
maps generated by factory
, and the table contents are all
serializable.
Note: the table assumes complete ownership over of backingMap
and the maps returned by factory
. Those objects should not be
manually updated and they should not use soft, weak, or phantom references.
backingMap
- place to store the mapping from each row key to its
corresponding column key / value mapfactory
- supplier of new, empty maps that will each hold all column
key / value mappings for a given row keyIllegalArgumentException
- if backingMap
is not empty@Beta public static <R,C,V1,V2> Table<R,C,V2> transformValues(Table<R,C,V1> fromTable, Function<? super V1,V2> function)
Changes in the underlying table are reflected in this view. Conversely, this view supports removal operations, and these are reflected in the underlying table.
It's acceptable for the underlying table to contain null keys, and even null values provided that the function is capable of accepting null input. The transformed table might contain null values, if the function sometimes gives a null result.
The returned table is not thread-safe or serializable, even if the underlying table is.
The function is applied lazily, invoked when needed. This is necessary
for the returned table to be a view, but it means that the function will be
applied many times for bulk operations like Table.containsValue(java.lang.Object)
and
Table.toString()
. For this to perform well, function
should
be fast. To avoid lazy evaluation when the returned table doesn't need to
be a view, copy the returned table into a new table of your choosing.
public static <R,C,V> Table<R,C,V> unmodifiableTable(Table<? extends R,? extends C,? extends V> table)
UnsupportedOperationException
.
The returned table will be serializable if the specified table is serializable.
Consider using an ImmutableTable
, which is guaranteed never to change.
@Beta public static <R,C,V> RowSortedTable<R,C,V> unmodifiableRowSortedTable(RowSortedTable<R,? extends C,? extends V> table)
UnsupportedOperationException
.
The returned table will be serializable if the specified table is serializable.
table
- the row-sorted table for which an unmodifiable view is to be returnedpublic static <R,C,V> Table<R,C,V> synchronizedTable(Table<R,C,V> table)
It is imperative that the user manually synchronize on the returned table when accessing any of its collection views:
Table<R, C, V> table = Tables.synchronizedTable(HashBasedTable.<R, C, V>create());
...
Map<C, V> row = table.row(rowKey); // Needn't be in synchronized block
...
synchronized (table) { // Synchronizing on table, not row!
Iterator<Map.Entry<C, V>> i = row.entrySet().iterator(); // Must be in synchronized block
while (i.hasNext()) {
foo(i.next());
}
}
Failure to follow this advice may result in non-deterministic behavior.
The returned table will be serializable if the specified table is serializable.
table
- the table to be wrapped in a synchronized viewCopyright © 2010-2017. All Rights Reserved.