Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-incubator-e4-dev] Avoiding Bloat

> I'm thinking about a SINGLE ImageRegistry / StringRegistry
> (could also be a database), from which plugins can acquire
> an image/String by means of a Key (that could be an int
> number, for instance). At the time a bundle is installed, all
> its images / Strings are placed into the common Database.
> Clients get a Key in return, which they can use at runtime
> to retrieve their data. Identical data is collapsed.
> Sounds interesting? Or am I missing something? Uninstalling
> a bundle would certainly not be easy, and I guess that the
> String and Image database would likely be an add-only thing

> to avoid lifecycle issues.

We have had great success in the past with JFace's LocalResourceManager. As long as the keys are not taking up more space than what you save through collapsing the real data, it sounds like a good idea.

LocalResourceManager is an object whose lifecycle is managed by its owner (usually some plugin), so lifecycle issues are not that problematic.  Each resource manager has a parent resource manager, but all resources (in the JFace case: Images, Colors, Fonts) are managed at the root resource manager, and reference-counted there.  By disposing your LocalResourceManager, the reference counts for all resources you contributed get decremented automatically. This also avoids the Singleton pattern... your all-caps SINGLE made me extremely nervous. ;-)

Not sure how you would use something like this for strings though.  Given a list of potentially not unique string objects, you can use a hash to uniquefy them, but it's computationally expensive if done synchronously and eagerly. (The resources plugin will uniquefy all strings used for markers, but it's done in a background job:


Back to the top