[
https://issues.apache.org/jira/browse/HBASE-19682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16317539#comment-16317539
]
BELUGA BEHR commented on HBASE-19682:
-------------------------------------
[~appy] I would simply point out that the List Add method is
[optional|https://docs.oracle.com/javase/8/docs/api/java/util/List.html#add-E-].
So if one does not know the source of the list, by convention and good
encapsulation, they should not be adding to it anyway, but instead adding it's
contents to a new list.
{code}
List<Foo> results = new ArrayList<> ();
results.addAll(getBaseFoos());
results.add(myfoo1);
results.add(myfoo2);
{code}
The JDK provides this emptyList mechanism for us to take advantage of. No
memory overhead, fast comparisons with ==, JVM hot-spot potential. There are
times where we may even wish to turn an otherwise mutable list into an
[un-modifiable|https://docs.oracle.com/javase/7/docs/api/java/util/Collections.html#unmodifiableList(java.util.List)]
list. The JavaDoc can provide the answers if we expand their usage. If you
really want to be conservative, we can wrap all return values in an
unmodifiableList so that the caller gets an immutable list no matter the
outcome of the method (empty or otherwise) and include that note in the
JavaDoc. In practice though, I just don't think it's a good idea to *ever* be
relying on the underlying function's return value to be the right collection
type. Maybe the method returns a LinkedList and now we're stuck adding objects
to it when we would otherwise prefer an ArrayList... maybe it's some sort of
home-brew List implementation that is completely whacky. Don't ever trust it
and blindly add items to it. Add the return value to a List that you know and
love, as was provided in the previous example. Simple rule to follow; No
problems.
There is reference to this in the book Effective Java, Third Edition; Joshua
Bloch. They suggest that Collections.empty() may be a pre-mature optimization,
but provide no qualms about it in regards to mutability. The example from the
book is as follows:
{code}
// Optimization - avoids allocating empty collections
public List<Cheese> getCheeses() {
return cheesesInStock.isEmpty() ? Collections.emptyList()
: new ArrayList<>(cheesesInStock);
}
{code}
> Use Collections.emptyList() For Empty List Values
> -------------------------------------------------
>
> Key: HBASE-19682
> URL: https://issues.apache.org/jira/browse/HBASE-19682
> Project: HBase
> Issue Type: Improvement
> Components: hbase
> Affects Versions: 3.0.0
> Reporter: BELUGA BEHR
> Assignee: BELUGA BEHR
> Priority: Minor
> Attachments: HBASE-19682.1.patch, HBASE-19682.2.patch,
> HBASE-19682.3.1.patch
>
>
> Use {{Collection.emptyList()}} for returning an empty list instead of
> {{return new ArrayList<> ()}}. The default constructor creates a buffer of
> size 10 for _ArrayList_ therefore, returning this static value saves on some
> memory and GC pressure and saves time not having to allocate a new internally
> buffer for each instantiation.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
