Q:

spring too many constructors argument using the same interface with qualifiers

This is more like a "good practice" question. 
let's say i have an interface "MyInterface" and about 15 implementations of it.  
I have an Object called "MyProcess" and the code looks like 
private final List<MyInterface> myInterfaces;

public MyProcess(@Qualifier("impl1") MyInterface impl1,
                 @Qualifier("impl2") MyInterface impl2,
                 @Qualifier("impl3") MyInterface impl3,
                 @Qualifier("impl4") MyInterface impl4,
                 @Qualifier("impl5") MyInterface impl5,
                 @Qualifier("impl6") MyInterface impl6,
                 @Qualifier("impl7") MyInterface impl7,
                 @Qualifier("impl8") MyInterface impl8) {

this.myInterfaces = Stream
            .of(impl1,
                impl2,
                impl3,
                impl4,
                impl5,
                impl6,
                impl7,
                impl8)
            .collect(toList());
    }

The goal is to define different processes using some of the implementations of MyInterface in a specific order.  The issue is that sonar rule S107 (constructor has 8 parameters which is greater than 7 authorized) is showing.  I was wondering if this was a code structure issue or if i just had to ignore sonar on this.  I dont feel like breaking SRP since the only goal of MyProcess is to define the list of MyInterface it needs.  
Does anyone have a clue on how i could improve this code ?  Maybe an other pattern to use ?  
Thank you in advance for your time

A:

One alternative is to add a method name() to MyInterface, which is implemented in each subclass as returning a constant String. 
public MyProcess(List<MyInterface> impls) {

  this.myInterfaces = new ArrayList<MyInterface>();
  for(String name: Arrays.asList("impl1", "impl2"...) {
     for(MyInterface impl: impls) {
       if(name.equals(impl.name())) {
         myInterfaces.add(impl); 
       }
     }
  }
}

I feel that hard-coding the names of the implementation in the process might not be ideal.  If you already have 15 implementations, the odds are that you might in the future have to add one.  And then you would need to update the Process as well. 
You let the MyInterface return something else than a name, e.g. a 'purpose' and a 'priority', so the process could wire new implementations automatically in the correct place, but that depends on your usecase.