core
the foundation of the platform

[home] [documents] [downloads] [resources] [planning] [testing]

Issues on the Radar
 
Property change listeners across scopes

Summary: In the old code, clients registered property change listeners so they would be notified when changes occurred to their preference value. Now this becomes more complicated since we have multiple places (scopes) where the preference values can be stored.

Right now clients must register preference change listeners on a per-node basis where the preferences are stored in a tree and each first-level child of the root is a sub-tree specific to a different preference scope. But at the client level, they are more likely to be interested in all changes to a particular preference, not just changes in a specific scope. If this is the case, clients don’t want to be concerned with adding a change listener to every node that holds onto that preference. (See bug 54392)

 
References to removed preference nodes

Summary: Preference nodes are not handles (like with java.io.File) and therefore the nodes can be removed while a client has a reference to one. If API is called on a removed preference node, then an IllegalStateException will be thrown. We need to consider what we can do to help clients. Perhaps making a handle-like interface is best? (See bug 54907)

 
Batched Event Processing

Summary: In the case where there are a lot of preference change events happening in sucession, clients are interested in receiving batch notification of these events. Fixing this will be tricky since we will have to add new API to handle the batch requests but we don't want to break people who currently are expecting a single event at a time. (See bug 77144)

 
Metadata associated with preferences

Summary: There are certain types of information that needs to be associated with preferences. Some examples of information are:

  • The user-interface needs to know a human-readable name to display to the user.
  • The preference could be marked as read-only.
  • The preference could be non-exportable.
  • Preference groupings and dependencies.
In essence, preferences need to have metadata associated with them. The problem is that Preferences are key/value pairs on node objects and not real objects themselves. This means that we cannot store metadata directly with the preferences. What we need is a way to store an association between preference keys and a group of metadata. Perhaps if the metadata itself was keyed and we used the full path of the node+key, we could use this (path -> metadata object) reference as a base for searching/storage of this information.

 
Change notification in the background

Summary: We would like to move preference change notification to the background to help prevent against bad client code. We have to be careful though because there are existing clients who have change listeners who are expecting the notifications to happen in the UI thread. In these cases they are making UI changes and will get an Invalid Thread Access error. (See bug 77280)

Update: Here is a document describing the issues in more detail.

 
Import/Export APIs

Summary: The new preference APIs allow plug-in developers to export on a per-node basis. This has proved to be confusing to users.