Avoid useless Plugin Initialization and/or Class Loading

 

Here’s a tip for initializing your plugins or any other singleton-like repository only when needed.

Consider a code like this:

if (isConfigurable()) {
  Bundle bundleCopy = bundle;
  Preferences[] preferencesCopy = new Preferences[1];
  preferencesCopy[0] = new org.eclipse.core.internal.
			preferences.legacy.PreferenceForwarder(
			this, bundleCopy.getSymbolicName());
  return preferencesCopy;
}
return null;

Do you see what’s wrong there?

The problem is that if your #isConfigurable is always FALSE then your code still:

  1. loads PreferencesForwarder class
  2. initializes all PreferencesForwarder’s static variables
  3. forces Preferences plugin to load

Always, if possible and makes sense, isolate your class loading into a simple Runnable inner class if there is some static init or plugin activation trigger involved!

Then the code would become:

if (isConfigurable()) {
  final Bundle bundleCopy = bundle;
  final Preferences[] preferencesCopy = new Preferences[1];
  Runnable innerCall = new Runnable() {
    public void run() {
      preferencesCopy[0] = new org.eclipse.core.internal.
			       preferences.legacy.PreferenceForwarder(
				 this, bundleCopy.getSymbolicName());
    }
  };
  innerCall.run();
}
return null;

When you think of it - this pattern is somewhat similar to the singleton pattern implementation - the one of the very few thread-safe and fast singleton patterns that is bugfree and truly lazy!

Quoting wonderful singleton impl from wikipedia:

public class Singleton {
   private Singleton() {}
   private static class SingletonHolder {
     private final static Singleton INSTANCE = new Singleton();
   }
   public static Singleton getInstance() {
     return SingletonHolder.INSTANCE;
   }
 }

(OK, to be fully honest, since java1.5 you can also trust volatile flags but - trust noone, use the old stuff:P)

For the reference, the PreferencesForwarder example was taken from the org.eclipse.core.runtime.Plugin#getPluginPreferences class and modified a bit.

UPDATE: This post is not fully correct! Never assume something to be true even if it comes from a trustworthy source like eclipse core runtime source. Please see the comments for explanation!

Share:These icons link to social bookmarking sites where readers can share and discover new web pages.
  • del.icio.us
  • digg
  • Reddit
Comments (3) Wednesday, December 19, 2:08 pm

Eclipse Top 5 Annoyances

Here is the list of Top 5 Eclipse Annoyances we came up today at the coffee-table, possibly nice to share (in the order of importance).

Also serves as a good wish-list to my Santa Claus!

1. Update Manager

With the help of p2 provisioning and hard work this will be hopefully solved for 3.5. Please don’t mess it up this time! :)

There was also some provisioning-related work done as part of 2007 Google Summer of Code.

When talking about “enemies” - Netbeans update manager is much more decent (yet less flexible)

2. Cannot have editors for “no-extension” files
no-Extension-Support bugzilla

Well, files without an extensions SHOULD be treated as any regular file - don’t make them feel like crap! :)

YET! At the same time we treat filenames without a filename properly - .project has the extension but no filename :P

3. Opening files from command line
command-line file opening bugzilla

Getting closer I hope, there is a summer-of-code project related to command line commands (about triggering eclipse actions from web-sites). Plus a proof-of-concept thin text-editor padclipse.

Dear Eclipse, give command-line file-open and other configurable command line options. My neighbor Netbeans has it, I want it too.

4. Word Wrap
word wrap bugzilla

HAHAHA! You can take it from here, the official eclipse word wrap page. It works but has it’s drawbacks like bugs with ruler line numbers etc.
More seriously - it won’t be there in any near timeframe IMHO. Architecturally there has been a little flaw in the very core of Eclipse - SWT.

In SWT StyledText making up all these editors is missing a difference between physical and visual line numbers. Because of that a lot of plugins use one set of API methods for both visual and physical line numbers. To make sure transition is causing no harm, existing API should probably keep showing physical line numbers. But that would break quite a few things - rulers etc.

Not sure how many 3rd party plugins use line info and how to treat them nice while transitioning. Or if that ever happens.

5. Split Editor
Split Editor bugzilla link

What the heck is with this feature? People vote and ask for it.

Do you really need this? You can have many editors for the same file anyway just by choosing New Editor from the tab view popup.

What’s your greatest Eclipse New-Year-Wish?

Share:These icons link to social bookmarking sites where readers can share and discover new web pages.
  • del.icio.us
  • digg
  • Reddit
Comments (10) Tuesday, December 18, 2:07 pm