I set Boot Class Path to "" and closed the dialog (windows style or cancel)
My change persisted.  This shouldn`t happen; after all, I selected cancel.

The change was only local to `CMD Java` (good job), but the cancel button should not be storing changes, it should revert to the values from before the dialog loaded (or be called "OK").

For completeness, I clicked help:
If you do not want to keep the customized settings, press the Cancel button to close the
customization window.

The behavior is inconsistent with the help.

[jglick] This is difficult to fix IMHO: normally Customize Bean is used on .java/.ser files which means you create an instance, customize, then maybe serialize back. In that situation Cancel is obviou
s. But a live Bean such as an Executor is simply changed when you change its property sheet, and Cancel does nothing to reverse the change; it can`t. Also the InstanceCookie which drives all this does
 not specify any particular way to clone the Bean, write changes back, etc. And there is no Bean Spec standard way of doing this anyway, except serializing and deserializing to clone if not Cloneable;
 writing changes back is not generally possible for non-Externalizable objects, if you want to keep object identity, i.e. you can only irreversibly change the original Bean or create a new Bean with t
he changes. Basically the architecture does not provide any good way to fix this bug. InstanceCookie may need to be rethought; InstanceCookie.Origin is almost certainly much too specific to be useful
generally; some explicit description of whether the Bean should be cloned, and how to save or reverse changes is necessary. Also see other S.T. suggestions (by me) re. general ideas for InstanceCookie

 + CustomizeBeanAction; and re. general notion of Cancel button for property sheet. Probably neither of these are good ideas but may be helpful to look at.