We Keep Coding

Any faster alternatives to isEmpty method for Set? [duplicate]

I have two ways of checking if a List is empty or not
if (CollectionUtils.isNotEmpty(listName))
and
if (listName != null && listName.size() != 0)
My arch tells me that the former is better than latter. But I think the latter is better.
Can anyone please clarify it?

You should absolutely use isEmpty(). Computing the size() of an arbitrary list could be expensive. Even validating whether it has any elements can be expensive, of course, but there's no optimization for size() which can't also make isEmpty() faster, whereas the reverse is not the case.
For example, suppose you had a linked list structure which didn't cache the size (whereas LinkedList<E> does). Then size() would become an O(N) operation, whereas isEmpty() would still be O(1).
Additionally of course, using isEmpty() states what you're actually interested in more clearly.

CollectionUtils.isNotEmpty checks if your collection is not null and not empty. This is better comparing to double check but only if you have this Apache library in your project. If you don't then use:
if(list != null && !list.isEmpty())

Unless you are already using CollectionUtils I would go for List.isEmpty(), less dependencies.
Performance wise CollectionUtils will be a tad slower. Because it basically follows the same logic but has additional overhead.
So it would be readability vs. performance vs. dependencies. Not much of a big difference though.

if (CollectionUtils.isNotEmpty(listName))
Is the same as:
if(listName != null && !listName.isEmpty())
In first approach listName can be null and null pointer exception will not be thrown. In second approach you have to check for null manually. First approach is better because it requires less work from you. Using .size() != 0 is something unnecessary at all, also i learned that it is slower than using .isEmpty()

If you have the Apache common utilities in your project rather use the first one. Because its shorter and does exactly the same as the latter one. There won't be any difference between both methods but how it looks inside the source code.
Also a empty check using
listName.size() != 0
Is discouraged because all collection implementations have the
listName.isEmpty()
function that does exactly the same.
So all in all, if you have the Apache common utils in your classpath anyway, use
if (CollectionUtils.isNotEmpty(listName))
in any other case use
if(listName != null && listName.isEmpty())
You will not notice any performance difference. Both lines do exactly the same.

Apache Commons' CollectionUtils.isNotEmpty(Collection) is a NULL-SAFE check
Returns TRUE is the Collection/List is not-empty and not-null
Returns FALSE if the Collection is Null
Example:
List<String> properties = new ArrayList();
...
if (CollectionUtils.isNotEmpty(properties)) {
// process the list
} else {
// list is null or empty
}
Refer:
https://commons.apache.org/proper/commons-collections/apidocs/org/apache/commons/collections4/CollectionUtils.html#isNotEmpty(java.util.Collection)

isEmpty()
Returns true if this list contains no elements.
http://docs.oracle.com/javase/1.4.2/docs/api/java/util/List.html

A good example of where this matters in practice is the ConcurrentSkipListSet implementation in the JDK, which states:
Beware that, unlike in most collections, the size method is not a constant-time operation.
This is a clear case where isEmpty() is much more efficient than checking whether size()==0.
You can see why, intuitively, this might be the case in some collections. If it's the sort of structure where you have to traverse the whole thing to count the elements, then if all you want to know is whether it's empty, you can stop as soon as you've found the first one.

Use CollectionUtils.isEmpty(Collection coll)
Null-safe check if the specified collection is empty.
Null returns true.
Parameters:
coll - the collection to check, may be null
Returns:
true if empty or null

The org.apache.commons.collections4.CollectionUtils isEmpty() method is used to check any collections(List, Set, etc.) are empty or not. It checks for null as well as size of collections. The CollectionUtils isEmpty() is a static method, which accepts Collection as a parameter.

I would use the first one. It is clear to see right away what it does. I dont think the null check is necessary here.

table.column = ANY(ARRAY[ :canEmptyArrayParameter ]::BIGINT[])
It helps me to check empty parameter of array
this parameter can be Collections.emptyList();

To Check collection is empty, you can use method: .count(). Example:
DBCollection collection = mMongoOperation.getCollection("sequence");
if(collection.count() == 0) {
SequenceId sequenceId = new SequenceId("id", 0);
mMongoOperation.save(sequenceId);
}

Check that array is empty, but not null

I have an array of objects (Object[] array), and I want to check whether it is empty, but fail fast if it is null with NPE or any other exception.
I know that I can do the following check
array.length == 0
but e.g. in case of String or collections it is not recommended practice, IntelliJ even has inspection for that:
Reports any .size() or .length() comparisons with a 0 literal which can be replaced with a call to .isEmpty().
Is there any replacement for .isEmpty() for arrays?
There is ArrayUtils.html#isEmpty(java.lang.Object[]), but it also checks for null, while I'd like to avoid that.

Because .size() is method, its implementation is hidden. And you can't be sure that this method optimized (there's a possibility, that some collections, for example, enumerate items every time you call .size() method). That is why computing the .size() of collection could be expensive. In the same time, .isEmpty() can checks just is there at least one item in collection, and return result.
But .length is just a field. It does nothing, just returns a value. There are no calculations. This field just stores the length of array with fixed size.
I believe that .size() and .length are totally different things and in this case they can not be compared, as well as collections and arrays.

The easiest way would to be to write such a method yourself. It would be fairly trivial. Something like the following
public boolean isArrayEmpty(Object[] array) {
if (array == null) {
//Throw nullpointer exception
//An easy of method of doing this would be accessing any array field (for example: array.length)
}
return (ArrayUtils.isEmpty(array));
}
That being said, there's very little reason why array.length == 0 would be harmful. It's the simplest, cleanest way to do this and does exactly what you want. Most likely part of the reason for ArrayUtils.isEmpty is to allow easy testing of whether or not a array is empty or null, a relatively common need, but you don't want to do that.

When to return empty collections and when not too?

This question regards to the function public List inorderTraversal ().
Assume a case the root is null, the returned List is empty, ie size = 0. I am confused now since this is same as Collections.emptyList(). When should we use Collections.emptyList ? Is this inorderTraversal right place to use it instead of list with size 0 ?

public static void main(String[] args) {
List l = Collections.emptyList();
l.clear(); // No NPE
List p = null;
p.clear(); // NPE
}
So, prefer returning emptyList rather than returning null..

Collections.emptyList is a very useful means of storing a reference to an empty list (which I guess is kind of obvious).
The benefit of using it is that it's only going to occupy the memory required for a single list. Using it saves you the memory that you would use if you had multiple empty lists lying around. Also, as it's static, this List instance will always exist, whether you use it once, a thousand times or not at all.
You should use it when you wish to return a "static" list containing no objects. I use the term "static" here to indicate that the list is empty and will not be populated by any means. For example, if you have a data-access object and do a database-retrieval that yields no objects then your accessor should return a Collections#emptyList
However, if you have a list that is being used dynamically (and becomes empty as part of this), such as to back a data-structure like your own List implementation, then you should not use it as you need to keep a reference to the active list.
Additionally, if (as you should) you return defensive copies of internal arrays, then you will be able to use Collections#emptyList for when the internal list is empty.

I would return an empty collection whenever it makes sense to do so. If you need to distinguish between an empty collection and "uninitialised" or some null state, then you can return null.

You can check the size of a resulting List just before return. If the size is 0, you can return Collections.emptyList(), so your empty ArrayList will become orphaned, and will be garbage collected.
Empty lists IMO a preferable to null, since they cat prevent NullPointerException

Put simply: yes. This way, if root is null you can avoid creating ArrayList (and consuming memory unnecessarily) .
Although this is not what you ask about, but generally returning empty collection is preferred over returning null - it prevents many NPEs.

Please note that Collections.emptyList() returns an immutable list, which means that adding to it, or removing from it will fail.
http://docs.oracle.com/javase/7/docs/api/java/util/Collections.html#emptyList()

Java: null of default value of object is better

The first case:
There is a class that has another class as its data member. When this class is instantiated, what we should do with the data member?
(A) In constructor: this.anotherClass = new AnotherClass();
(B) left it null, no need to instantiate it.
The second case:
There is a class that has an ArrayList as its data member. When this class is instantiated, what we should do with the ArrayList?
(A) In constructor: this.bulidingList = new ArrayList< Building >();
(B) left it null, no need to instantiate it.
The third case:
when we create a method in which its return type is a collection, for example
public ArrayList< Building > getBuildingList(){
/// Bah Bah Bah..
}
if there is no Building, we should return the empty ArrayList "new ArrayList< Building >()" "or null.

I would prefer not using null to avoid potential NullPointerException's. To avoid creating unnecessary objects you could construct a single static instance to return, as long as it's immutable. As for an empty ArrayList, you can use Collections.emptyList() to do this for you.
In the end it's up to you how you want to define how your API works. Either way you should clearly document it so the caller knows what to expect.

What are your needs? My general preference is to return null when possible as this avoids creating another object in memory.
Provided that you ensure the documentation clearly states that the method may return null and it is the responsibility of calling code to handle that, I don't see a problem.

There is no concrete answer. It is a case of your API, or, speaking simpler, the expectations of the surrounded code.
Try to think in details about your getBuildingList(). Is it ok to return null? Or null is forbidden and you should return empty list?
Anyway, docuemtn you thoughts in javadoc for the method.

Given the destructive nature of Nulls in Java, I think it's a good practice to return empty collections rather then null collections.
For Objects, you should return "null" if the object has no values set internally.

Is a default-initialized object meaningful, as an empty ArrayList certainly is? Then instantiate it. Don't optimize prematurely.
On the other hand, if a default AnotherClass makes no sense, then leave the member as null.
Finally, if you run into performance or memory usage problems, consider revising the design.

In my opinion, it is best to design your APIs to avoid returning a null if there is a better alternative.
For collections, return an empty collection; e.g. Collections.emptyList() or new ArrayList() ... depending on the API requirements.
For arrays, return an array of length zero.
For objects, consider whether it is feasible to use a distinguished instance of the class, or to design the API so that the result can't be null in the first place.
If you do need to return null, or accept null as a method parameter, make sure that the javadoc clearly states that this is a valid result / argument ... and what it means.
The problem with APIs that use null is that developers forget about the null case and the result is an unexpected NullPointerException. You could say that's not the API designer's fault - the API user should have read the documentation. But that doesn't really address the issue. A better approach is to avoid returning the null in the first place, especially in cases where there is a simple alternative.
The other point is that a non-null value is generally easier for the caller to deal with. A null typically has to be dealt with as a special case by the calling code. A non-null value doesn't. For example, you can iterate over an empty collection or array using a for loop, but a null has to be tested for explicitly.

The third case: when we create a
method in which its return type is a
collection, for example
public ArrayList< Building > getBuildingList(){ /// Bah Bah Bah.. }
This is awful, a public member should never return an implementation type. The signature should be:
public List< Building > getBuildingList()
That way you can (and should) return Collections.emptyList() if your data is empty.

The first case: There is a class that has another class as its data member. When this class is instantiated, what we should do with the data member?
(A) In constructor: this.anotherClass = new AnotherClass();
(B) left it null, no need to instantiate it.
I would prefer (C) In constructor: require a non-null AnotherClass parameter.
If you need a default constructor and you always expect the caller to also call setAnotherClass() afterwards you could leave it null in the constructor and check for null when you actually use the field, otherwise you should probably create a default AnotherClass object in the constructor.
The second case: There is a class that has an ArrayList as its data member. When this class is instantiated, what we should do with the ArrayList?
(A) In constructor: this.bulidingList = new ArrayList< Building >();
(B) left it null, no need to instantiate it.
I would always instantiate it, but if the list is read-only I'd declare it this way instead:
List<Building> buildingList = Collections.emptyList();
The third case: when we create a method in which its return type is a collection, for example
public ArrayList< Building > getBuildingList(){ /// Bah Bah Bah.. }
if there is no Building, we should return the empty ArrayList "new ArrayList< Building >()" "or null.
I'm not especially proud about it, but I do sometimes return null when I want an additional return value, something like getBuildingsListAndReturnNullIfThereAreNoTenants. When you just want to say "I haven't found any buildings" it's always better to return an empty list instead.
Sometimes you can do an upfront check and return Collections.emptyList() instead of creating a new ArrayList<Building> instance, but I wouldn't go out of my way to do it.

Use of array of zero length

For example we can construct such an array like this:
new ElementType[0];
I seen such a construct, but I don't understand why this might be useful.

An example. Say, you have a function
public String[] getFileNames(String criteria) {
to get some filenames. Imagine that you don't find any filenames satisfying criteria. What do you return? You have 2 choices - either return null, or 0-sized array.
The variant with 0-sized array is better, because your caller doesn't need to check for NULL and can process the array in a consistent way - say, in a loop (which would be empty in this case).
There's a chapter on this in Effective Java, Item 27

It's easier to work with than null in many cases, where null is the obvious alternative.
Suppose you want to return an Iterable<String> containing (say) a list of relevant filenames... but there aren't any for some reason. You could return null to indicate that, but then the caller has to special-case that. Instead, if you return an empty collection, the caller can still use an enhanced for loop:
for (String file : getFiles())
So why use an empty array instead of an empty ArrayList or something similar? Arrays are a fixed size, so an empty array is effectively immutable. That means you can keep a single value and return it to whoever you like, knowing they can't possibly do anything with it. That can be very useful in some situations.

it is a replacement for null since you don't need to check for null before use it.
More formally it is a special case of special case design pattern (check also Null Object).
Another idiomatic use is collections toArray:
List<String> list = new ... ;
// fill the list
String[] array = list.toArray(new String[0]);