It's not a contradiction - a .settings file? can actually represent a SystemOption - but it doesn't necessarily. A .settings file can represent an instance of any Java class that has a default, no-argument constructor. You can use .settings files to instantiate POJOs of your choice, so instead of using SystemOption, you can create a simple JavaBean and refer to that. If it is to be used in the options dialog, you probably want to supply a BeanInfo so properties will have localized names, etc.

.settings files are sometimes used to define SystemOptions for performance reasons - because .settings files make it possible to show a display name and an icon for an object without actually creating it. This technique is particularly used in two places:

  • The window system, because we don't want to instantiate all the windows the user might ever open on startup, and using the alternative, .instance files? would cause that
  • The Options dialog (the UI/ folder of the System Filesystem) - the options

dialog will show a tree of objects from most modules in the system; if all of those objects were really created, there would (in fact there used to be) a storm of furious classloading as the IDE creates all of the objects in the tree - even though typically the user only changes one or two settings when the open the Options window.

Source: NetBeans FAQ