Note: Edited to reflect Dragon’s modified requirement to make it work upon selection.

A common pattern to generalize this sort of thing is an adapter. Have an abstract class called GUIAdapter which can tinker with the individual gui aspects of your program according to the settings:

public abstract class GUIAdapter {
    public abstract void adapt(GUIFrame frame);
    public abstract void remove(GUIFrame frame);
}

Then override GUIAdapter with adapters suitable for each type of situation:

public class WindowsGUIAdapter extends GUIAdapter {
    public void adapt(GUIFrame frame) {
        // Things to do when windows operating system
    }
    public void remove(GUIFrame frame) {
        // Remove trace of WindowsGUIAdapter
    }
}

public class LinuxGUIAdapter extends GUIAdapter {
    public void adapt(GUIFrame frame) {
        // Things to do when linux operating system
    }
    public void remove(GUIFrame frame) {
        // Remove trace of LinuxGUIAdapter 
    }
}

public class TomcatGUIAdapter extends GUIAdapter {
    public void adapt(GUIFrame frame) {
        // Things to do when using tomcat server engine
    }
    public void remove(GUIFrame frame) {
        // Remove trace of TomcatGUIAdapter 
    }
}

// et cetera ...

These adapters have as much or as little control as you let them have over your frame. When the operating system or server is known, you call “remove” on all existing adapters, add the appropriate adapter for the current selection, and then call “adapt” to apply the configuration for current selection. I would recommend that you would add a panel to the frame and remove it when “remove” is called. Keep a reference to JPanel as a private member of your extended class of GUIAdapter in order to be able to remove it easily afterwards.

Notice that I didn’t make a WindowsTomcatGUIAdapter. The idea is that your GUIFrame class (I’ll assume that’s what it’s called) houses a list of adapters which get called to modify the state of the frame according to the selection without knowing how they work.

public class GUIFrame extends JFrame {
    // Other protected variables here
    private List<GUIAdapter> adapters = new ArrayList<GUIAdapter>();

    private JList serverList, osList;

    private SERVERS selectedServer = null;
    private OS selectedOS = null;


    public GUIFrame() {
        initialize();
    }

    private void initialize() {
        // Do things common to all here

        // Operating system select event
        ListSelectionListener refreshOptionsListener = new ListSelectionListener() {
            public void valueChanged(ListSelectionEvent listSelectionEvent) {
                selectedOS = (OS)osList.getSelectedValue();
                selectedServer = (SERVERS)serverList.getSelectedValue();

                refreshAdapters();
            }
        };

        // Instantiate osList
        osList = new JList();
        // ...
        osList.addListSelectionListener(refreshOptionsListener);

        // Instantiate serverList
        serverList = new JList();
        // ...
        serverList.addListSelectionListener(refreshOptionsListener);
    }

    private void refreshAdapters() {
        for(GUIAdapter adapter : adapters) {
            adapter.remove(this);
        }
        adapters.clear();

        if(os == OS.WINDOWS) {
            adapters.add(new WindowsGUIAdapter());
        } else if (os == OS.LINUX) {
            adapters.add(new LinuxGUIAdapter());
        } // else if () ...

        if(server == SERVERS.TOMCAT) {
            adapters.add(new TomcatGUIAdapter());
        } // else if () ...

        for(GUIAdapter adapter : adapters) {
            adapter.adapt(this);
        }    
    }

    // Other class logic here
}

Now you’ve decoupled all logic pertaining to operating system or engine with the classes which perform this logic. Whenever a new operating system or a new server is selected, current adapters are removed and new adapters are added. If no operating system or server is selected, then no adapter is added (no condition is met in if/else chain since selectedOS or selectedServer would be null), which is fine. The frame is not adapted since no adaptation is required as you would expect.

This pattern works well only if server adapters do not really need to know what operating system is being used or inversely, if operating system adapters do not really need to know what server is being used. However, if you find yourself in that situation, you should create a WindowsTomcatGUIAdapter which deals with just that particular case rather than attempt to make WindowsGUIAdapter and TomcatGUIAdapter work well together (as that would create coupling once again). Future additions are literally as simple as adding a new class and plugging them in on initialization.

Presumably, you could extend this logic to include validation or whatever other type of logic particular to that particular adapter.

I guess what you are looking for is some kind of decision table. For each possible combination of OS, server and GUI element store a boolean flag indicating the visibility. You could simply utilize a 3 dimensional boolean array (bool[][][] uiVisibility) for that task, indexed by enums indicating the OS, the server and the particular UI element. And you GUI initialization code then will just look like this:

    userNameField.setEnabled(uiVisibility[osIndex][serverIndex][UIelem.userNameField.getValue()]);
    userPasswordField.setEnabled(uiVisibility[osIndex][serverIndex][UIelem.userPasswordField.getValue()]);

As you see – no switch/case any more, and the visibility setting code is in just one place.

Note that it is much more likely that your list of GUI elements will grow than the list of OSs or servers – at least as long as you don’t have to distinguish between different OS versions or server versions.

EDIT: if this is the right tool for the job depends. First, a decision table is definitely much better maintainable then to duplicate the same setEnabled code 12 times, with minor modifications between that blocks (note that Neil’s suggestion does not solve that problem, it just hides it because he does not show the // Things to do part in his answer)

The key is how you initialize the table. You have different options for that, for example, using standard array initialization. If you have only minor differences between the 12 combinations, there is also the option to create a default initialization for all blocks in the decision table (or a default initilization for each OS) and add some small code writing only that modifications for specific combinations of server/OS.

If your configuration is composed of boolean values, I think what you could have is the following structure comprising a BitSet:

class OSConfiguration {
  private BitSet configurationFields;

  public OSConfiguration() {
    configurationFields = new BitSet();
  }

  // you can allow checking if a given bitset index is set or not
  public boolean isFieldEnabled(int index) { return configurationFields.get(index); }

  // ... or create proper getter/setters
  public boolean isUserNameFieldEnabled() { return configurationFields.get(3); }
  public void setUserNameFieldEnabled(boolean value) { configurationFields.set(3, value); }
  // all other fields could be done like that
}

And the following TreeMap:

TreeMap map = new TreeMap<SERVERS, Map<OS, OSConfiguration>>();

// to check if an OS configuration is available for a given server:
boolean isAvailable = map.get(SERVERS.TOMCAT).containsKey(OS.WINDOWS);

// to get an entire configuration:
OSConfiguration configuration = map.get(SERVERS.TOMCAT).get(OS.WINDOWS);
// to check if a given configuration is enabled:
boolean isEnabled = map.get(SERVERS.TOMCAT).get(OS.WINDOWS).isUserNameFieldEnabled();

Now, even if your OS configuration needs to have more than just boolean values, since you’ve hidden that in the OSConfiguration class, you can do whatever you want.

In any case, I suggest to keep it simple.