First, I want to point out the excellent back and forth in the comments that shows the issue is nuanced – and often a religious debate.

There are many Java-specific comments about different frameworks, etc. – but I think the real meat of a question like this should stand alone from a specific framework choice and possibly even language.

I think the question you didn’t ask was: “Does my object need seven others to work properly?” This may be a design smell – or it might be completely normal at a high-level tier of your complex program. This is the question I would ask first – any weirdness about the number of inputs doesn’t change depending on the method of object creation.

Once it’s known that all these objects as inputs do make sense, then it comes down to how the object is created. To @Robert Harvey’s point, it’s important to have a fully-baked object, or else you have to check if the object is good before you do any work anywhere in the object. I have seen that type of code and it tends to be less maintainable – I feel I can say that objectively. All arguments coming in on constructors is a nice clean way to do this, but if your inversion of control framework does it via private properties – does it matter? Protection exists in both cases.