Settings in NetBeans 3.5

$Revision: 1.3 $
Changes: available in CVS

This document summarizes state of the settings in NetBeans 3.5.

Current state

NetBeans uses extensively JavaBeans model and settings are not an exception. The current settings system could be characterized as: everything is serializable JavaBean. The typical lifecycle of this bean is:

• bean is declaratively defined in module's layer
  
• instance of the bean is created and loaded into memory on demand
• system listener is attached to the bean instance and change of bean's properties will result in scheduling of automatic save of the bean instance
• property sheet is generated for the bean instance and it is presented somewhere in the UI so that users can customize bean
  
• Java Serialization is used for persistence of modified beans

The concept of layers is used that:

• module declaratively defines bean in its module layer
• module layers are merged into one layer which presents default configuration layer of the application
• customizations of beans are stored in separate customization layer of the application
• the customization layer lies above the default configuration layer - all stored customization has precedence over the default ones
• the customization layer together with default configuration layer form application configuration system
  

Problems of current state

This system has following pros and cons:

Beans pros:

• The client does not have to do anything apart from implementing Serializable on its bean and will get for free persistence, UI customization and automatic saving of changes. However implementing this idea is almost impossible as you will see in next section.

Beans cons:

• Java Serialization has proven as not reliable for more complex applications. The serialization itself if properly implemented is realiable. But is has a few pitfalls and limitations which programmers are usually not aware of and will learn about them hard way during the upgrading of old settings to newer version of application.
• Listening on bean changes and saving it automatically can cause performance problems if bean is visual beans which properties are changing often (eg. TopComponent)
  
• Property sheets as the main and only UI element for customization of bean has proven unsufficient.
• Everything must be a bean. In order to store a setting the serailizable bean has to be created. There is no support for storage of primitive data types.
  

A few of the above mentioned problems were already addressed by core/settings module. The module has concept of convertors which are used instead of Java Serialization and can persist object in any format; has support for versioning of persisted data and can influence saving strategy of the object. However this mechanism although good is too complex for the modules and as a result it was not widely accepted and most of the modules still rely on serialization and therefore on all the above mentioned problems.

Layers pros:

• The concept of layers is powerful and desired to keep. It gives modules declarative way to participate on the default behaviour of application. Storing user's customization in separate customization layer allows return to the default application state simply by discarding all the customizations.

Layers cons:

• Current problems lie mostly in the implementation of this concept. There is missing rich validation of module layers and the declarative API it constitutes. The module layers are XML files validated only againts the XML Filesystem DTD. This makes using of layers too error prone.
• The default configuration layer and customization layer are hidden in the core implementation and publicly accessible only as SystemFilesystem. The usage of Filesystems API for accessing configuration of application has proven as limiting and unsufficient. It also uselessly manifest the internal implementation of the configuration system. The fact that the two layers are hidden in core means that reverting of user's customization can be done only in core and so all UI elements doing this must be done in core as well.
  

Other important defficiency of current settings system is that there is no single Settings API library. The current solution is spread across the NetBeans core. The Filesystems library and Datasystems have to be used when working with settings. Especially the Datasystems are heavily used for settings handling what in the light of cancellation of this API means that replacement must be created anyway.

Some other issues are summarized in Accessing and sharing modules' resources document.