There is not a great way in Jenkins databinding to handle String[]-valued properties. The general best practice is to make the property name as understood by Stapler (data binding) match the property name as understood by XStream (serial form), and for the type of both to be natural (a collection of some kind rather than a text blob). This makes for more consistent and predictable interaction with ways of defining job configuration other than the web UI. This tends to matter for the Workflow plugins (Describable objects instantiated as part of Step configuration from the Groovy DSL); Job DSL plugin; YAML Project plugin; etc.

This commit gives an example of how you can make these align, even using the standard textarea.jelly control. The trick is to override Descriptor.newInstance. This is awkward though, and prevents you from using automatic databinding for other properties of the same class.

It would be preferable to have a standard form control dedicated to representing a list of strings, probably rendered as a textarea (split on newlines and whitespace trimmed), though a series of textboxes with Add/Remove buttons is also an option. The representation created by buildFormTree should be a JSON array, which I believe Stapler already knows how to bind to Java arrays and/or lists; and FormChecker would ideally let you use a collection type in @QueryParameter for doCheck* methods as well. (Using a Set<String> as the property type is dubious, because duplicates will be silently deleted when the form is saved. Perhaps better to use a FormValidation warning to alert the user if duplicates are unwanted for the particular property.)