In my opinion it depends on the situation. The example you listed is a pretty simple class with only simple types. I would consider that all right. However, I am not really sure about your statement considering setters. But there is something you might have to consider:
If you are working with some of the bigger frameworks (Spring, Hibernate...) a lot of them will instantiate objects using a default constructor (like new Person()) and then call setters for fields. They will throw exceptions if something is not available.
Having a constructor like the one you listed is fine. But setters would be needed anyway. If they get complex, consider refactoring the class. Maybe too many dependencies are needed. Maybe instead of having 10 parameters you can encapsulate them in another object (for example a configuration).
Try to not make fields public. When at some point you have to check for a certain condition in a setter and your field was public, you'll spend some time refactoring that. Check for preconditions in setters if needed and throw exceptions.
I also found this question on stackoverflow, which takes the question about setters a bit further: Java setting private fields inside constructors