hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "BELUGA BEHR (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-19682) Use Collections.emptyList() For Empty List Values
Date Tue, 09 Jan 2018 02:03:00 GMT

    [ 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)

Mime
View raw message