What interface represents a LinkedHashSet with insertion order iteration

Question

I am being pulled up by Sonar due to the following line of code:

public void setFileNames(LinkedHashSet<String> fileNames) {

With the error message:

Avoid using implementation types like 'LinkedHashSet'; use the interface instead

What is the way around this when I want to represent a non-sorted Set which keeps its insertion order? Do I just use a Set and make it clear that the iteration order will be kept?

The stored data will be serialized using JaxB and the iteration order is essential after deserialization.

(I am aware of and completely understand this)

Answer 1

There is no such interface as it makes no sense to require this behavior for an input. Code creating a Set might have an intention about the order and choose an appropriate implementation when creating the Set.

But how can the question whether a Set has an insertion order, alphabetical order or an arbitrary, e.g. hash based, order make a difference for a method like setFileNames(Set<String> fileNames)?

Declaring the parameter type as Set gives you the guaranty that there won’t be duplicates which has an impact on the behavior, but the insertion order is a meaningless information (unless the caller makes it meaningful) about the history of the Set.

If you insist on having a method signature setFileNames(LinkedHashSet<String> fileNames), I still can pass in a Set with a meaningless order, e.g. calling
setFileNames(new LinkedHashSet<String>(hashSet)) or a set with lexicographical order, e.g. setFileNames(new LinkedHashSet<String>(treeSet)). Your signature makes it only more complicated.

Answer 2

I appreciate the other answers, and I also appreciate the Sonar warning. However, sometimes (like perhaps in your case) its okay to ignore the warning. It seems to me that you are using LinkedHashSet to precisely define the responsibilities of the caller. Set doesn't communicate your requirements (order not preserved). Neither does List (distinct elements not guaranteed). So perhaps it's okay to ignore this warning.

An alternative is that you allow a List and then you have to double check (inside your method) that the list has no duplicates and throw an exception if there are. That seems ridiculous to me.

As others stated, you should just figure out how to suppress the warning in Sonar. Hopefully that mechanism has a way to include a reason why you suppressed it. Then you can explain your decision to future maintainers.

Answer 3

Just accept a Set, let the caller decide what implementation to pass in.

which keeps its insertion order?

That's up to the caller. LinkedHashSet preserves order base on insertion, TreeSet preserves order based on natural ordering. Why should your method care how order is achieved?

Answer 4

If you need the elements that you are receiving to be ordered, then your method should receive a List and not a Set. But in order to get rid of the warning, you would have to use Set and not LinkedHashSet. It is good practice to use interfaces and not actual classes in your methods. You shouldn't expose actual implementations of an interface.

Also, if all you need is to iterate through the elements of the Set, you could receive an Iterator, and just iterate through it.

EDIT: If you really want to ensure that you only receive a LinkedHashSet, you can do something like this:

public void setFileNames(Set<String> fileNames) {
   if (!(fileNames instanceof LinkedHashSet)) {
      throw new IllegalArgumentException("I need a LinkedHashSet!");
   }
}

EDIT 2: I don't think there is an ideal answer here, but if you do really need above all things receive a LinkedHashSet, I would declare it in the interface and find a way to make Sonar to ignore that specific instance of that warning.