Respostas:
A principal diferença é que Collections.emptyList()
retorna uma lista imutável , ou seja, uma lista à qual você não pode adicionar elementos. (O mesmo se aplica ao List.of()
introduzido no Java 9.)
Nos casos raros em que você não deseja modificar a lista retornada, Collections.emptyList()
e List.of()
, portanto, são não uma boa escolha.
Eu diria que retornar uma lista imutável é perfeitamente adequado (e até a maneira preferida), desde que o contrato (documentação) não explique explicitamente de maneira diferente.
Além disso, emptyList()
pode não criar um novo objeto a cada chamada.
As implementações desse método não precisam criar um objeto List separado para cada chamada. O uso desse método provavelmente terá um custo comparável ao uso do campo com o mesmo nome. (Diferentemente deste método, o campo não fornece segurança de tipo.)
A implementação da emptyList
aparência é a seguinte:
public static final <T> List<T> emptyList() {
return (List<T>) EMPTY_LIST;
}
Portanto, se seu método (que retorna uma lista vazia) for chamado com muita frequência, essa abordagem poderá fornecer um desempenho um pouco melhor, tanto na CPU quanto na memória.
NullPointerException
retornando em Collections.emptyList()
vez de null
.
Collections.emptyList()
é iterável e retorna um comprimento, para que possa ser usado em loops sem que uma exceção seja lançada.
new ArrayList<>()
também torna clara a decisão de design; elementos não serão adicionados a esta lista.
A partir do Java 5.0, você pode especificar o tipo de elemento no contêiner:
Collections.<Foo>emptyList()
Concordo com as outras respostas que, nos casos em que você deseja retornar uma lista vazia que permanece vazia, você deve usar essa abordagem.
List<Foo> list = Collections.emptyList()
Collections.emptyList
é imutável; portanto, há uma diferença entre as duas versões; portanto, você deve considerar os usuários do valor retornado.
O retorno new ArrayList<Foo>
sempre cria uma nova instância do objeto, por isso tem um custo extra muito pequeno associado a ele, o que pode lhe dar um motivo para usá-lo Collections.emptyList
. Eu gosto de usar emptyList
apenas porque é mais legível.
Tenha cuidado, porém. Se você retornar Collections.emptyList()
e tentar fazer algumas alterações com algo assim add()
, você terá um UnsupportedOperationException()
porque Collections.emptyList()
retorna um objeto imutável.
Eu aceitaria Collections.emptyList()
se a lista retornada não estivesse sendo modificada de forma alguma (como a lista é imutável), caso contrário, eu iria com a opção 2.
O benefício de Collections.emptyList()
é que a mesma instância estática é retornada a cada vez e, portanto, não há criação de instância ocorrendo para cada chamada.
Use Collections.emptyList () se quiser garantir que a lista retornada nunca seja modificada. É isso que é retornado ao chamar emptyList ():
/**
* The empty list (immutable).
*/
public static final List EMPTY_LIST = new EmptyList();
Collections.emptyList()
tinha um custo de construção. Ver os detalhes da implementação (embora provavelmente não seja o mesmo em todas as JVMs) confirma que não. @Atul, de que JVM é essa?
As respostas dadas enfatizam o fato de emptyList()
retornar um imutável, List
mas não fornecer alternativas. Os ArrayList(int initialCapacity)
casos especiais do Construtor , 0
portanto, retornar em new ArrayList<>(0)
vez de new ArrayList<>()
também pode ser uma solução viável:
/**
* Shared empty array instance used for empty instances.
*/
private static final Object[] EMPTY_ELEMENTDATA = {};
[...]
/**
* Constructs an empty list with the specified initial capacity.
*
* @param initialCapacity the initial capacity of the list
* @throws IllegalArgumentException if the specified initial capacity
* is negative
*/
public ArrayList(int initialCapacity) {
if (initialCapacity > 0) {
this.elementData = new Object[initialCapacity];
} else if (initialCapacity == 0) {
this.elementData = EMPTY_ELEMENTDATA;
} else {
throw new IllegalArgumentException("Illegal Capacity: "+
initialCapacity);
}
}
(fontes do Java 1.8.0_72)
Collections.emptyList()
mais adequado para, digamos, verificação de erros e afins?