Bug 79909 [JFace] Localized resource registries for JFace
Please provide improved JFace support for managing SWT resources, with the following properties: - A registry can allocate and deallocate SWT resources given a descriptor - Resources are reference-counted and shared, allowing different objects with equivalent descriptors to share resources. - Everything in the registry can be deallocated with one function call - The registry should support an open-ended set of resources (and should initially support, at minimum, Images, Fonts, Colors) - It should be possible to create a "local registry" that behaves like a regular registry but actually shares its resources with a global registry. For example, the workbench could offer a local registry as a service to views and editors. This would allow views and editors to safely allocate and deallocate SWT resources without any chance of leaking.
bundles/org.eclipse.jface/src/org/eclipse/jface/resource/ColorRegistry.java
import java.util.List;
import java.util.Map;
import java.util.Set;
import org.eclipse.jface.util.Assert;
import org.eclipse.swt.graphics.Color;
import org.eclipse.swt.graphics.RGB;
import org.eclipse.swt.widgets.Display;
/**
 * A color registry maintains a mapping between symbolic color names and SWT 
 * <code>Color</code>s.
 * <p>
 * A color registry owns all of the <code>Color</code> objects registered with 
 * it, and automatically disposes of them when the SWT Display that creates the 
 * <code>Color</code>s is disposed. Because of this, clients do not need to 
 * (indeed, must not attempt to) dispose of <code>Color</code> objects 
 * themselves.
 * </p>
 * <p>
 * Methods are provided for registering listeners that will be kept
 * apprised of changes to list of registed colors.
 * </p>
 * <p>
 * Clients may instantiate this class (it was not designed to be subclassed).
 * </p>
 * 
 * @since 3.0
 */
public class ColorRegistry extends ResourceRegistry {
    /**
     * This registries <code>Display</code>. All colors will be allocated using