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:
- loads PreferencesForwarder class
- initializes all PreferencesForwarder’s static variables
- 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!
Reason to serialVersionUID your serializable classes
Quoting Eclipse FAQ: “When classes compiled in Eclipse are written to an object stream, you may not be able to read them back in a program that was compiled elsewhere. Many people blame this on the Eclipse compiler, assuming that it is somehow not conforming properly to spec. In fact, this can be a problem between any two compilers or even two versions of a compiler provided by the same vendor. If you need object serialization, the only way to be safe is to explicitly define the serialVersionUID in your code! /…/ Bottom line: Always define the serialVersionUID explicitly in your source files.”
My question is: can there be an audit to automatically detect source files where you explicitly defined serialVersionUID that is out of date? A nice-to-have addition would be a quick-fix for repairing serialVersionUID. Current eclipse quick-fix supports only generating serialVersionUID from scratch.
Welcome back, dear word-wrap
At first sorry about those who have been checking for an update of this blog for a month. Regardless of this inactivity there have been quite a lot visitors. I’m glad to see that people like what I’m doing. Thank you!
There have been busy days and let’s admit - weather in Estonia has been shiny and warming :)
Amazing how much feedback and interest has eclipse word-wrap plugin generated. Before starting this project I didn’t realize how important wordwrapping is for so many of us. 
All(most) java developers have been wasting time on scrolling just to see all implemented interfaces. People are really using first versions of wordwrap and are eagerly waiting for a version that works properly with line numbers etc.
What they do not know is how complex this will be :)
No hope is lost and I’m still working to come up with a better version. New versions of plugin were delayed because I just couldn’t use any of the code from the first version. It used mechanisms that are poorly designed in eclipse (more specificly StyledText and it’s wrap flag). Or, let’s rephrase it for the sake of political correctness - StyledText is not meant to provide separate model for wrapped text. But different editor components need different kind of models (wrapped and unwrapped).
The other critical issue is with the performance. At least for now there are going to be two duplicated and synchronized models: wrapped and unwrapped. It would be ok to have wrapped model only for the visible part but eclipse viewer mechanism is not supporting this idea very well. Because of this and several other factors not mentioned here it’s not very likely that word wrap feature will be in eclipse core in near future (1-2 years?).
We decided to take a bit different approach than planned and I’m creating an installable plugin that is patching your eclipse platform text component. There will be an option for turning word wrap on and off. But more about it later when there is a package ready that is at least as usable as was the version 0.0.2.
As you see, I’ve added a new tab at the top of this blog - “Eclipse Word-Wrap”. It will have a better face and content as soon as the new version of plugin comes out - my promise. So far it’s a place for grabbing the eclipse update url.
Stay tuned and have fun, you word wrap freaks :)
Lazy-init variables are not always safe
Have you ever used following to lazy-initialize your variable?
If you have then don’t.
Just to remind or introduce, it looks OK but it isn’t - this is a pretty serious bug you can easily make.
And it’s called Double-Checked Locking.
Very good and easy-to-understand explanation is here
