a quick workaround is to listen to laf changes and re-set the columns wrapped into invokeLater.
just copying my musings from the thread:
The technical reason is that the editor is under the control of the ui, that is recreated and set in its installUI (if the current editor is null or UIResource). It doesn't configure the textField except for the format, so at the end of the day, the column setting is lost.
So another workaround might to set a custom editor which is not of type UIResource - the ui installed one does some tricksery to return a reasonable pref if empty and columns not set ...
A real solution might (just musing, input welcome!):
Make the columns a property of the datePicker: that way it would we stored in the picker and propagate to the editor as needed. Slightly worried that doing so might open a flood gate: once started we might end up with tons of propagated properties. Hmm, need to check others, like font etc: they are passed through to the editor without being kept in the picker, might be lost on updating the ui.
Alternative, make the ui keep track of the columns if set in the editor (could store as a client property in the picker on uninstall). Feels hacky..
There's an old ui-property with key JXDatePicker.numCols which isn't (never was?) actually used - using it, would allow to some per-application setting