Comments on: Avoid useless Plugin Initialization and/or Class Loading http://ahtik.com/blog/2007/12/19/avoiding-useless-plugin-initialization-andor-class-loading/ blog Tue, 31 Jan 2012 22:08:00 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Ahti http://ahtik.com/blog/2007/12/19/avoiding-useless-plugin-initialization-andor-class-loading/comment-page-1/#comment-106 Ahti Thu, 20 Dec 2007 09:47:55 +0000 http://ahtik.com/blog/2007/12/19/avoiding-useless-plugin-initialization-andor-class-loading/#comment-106 Sometimes respective source code like eclipse runtime is so trustworthy that one stops thinking if it's really correct :P Sometimes respective source code like eclipse runtime is so trustworthy that one stops thinking if it’s really correct :P

]]> By: Ahti http://ahtik.com/blog/2007/12/19/avoiding-useless-plugin-initialization-andor-class-loading/comment-page-1/#comment-107 Ahti Thu, 20 Dec 2007 09:43:05 +0000 http://ahtik.com/blog/2007/12/19/avoiding-useless-plugin-initialization-andor-class-loading/#comment-107 Mark: Haha! How embarrassing, you were right :) Plugin source code has a comment regarding this and it was clearly misleading: // Performance: isolate PreferenceForwarder into // an inner class so that it mere presence // won't force the PreferenceForwarder class // to be loaded (which triggers Preferences // plugin activation). True, of course it makes sense that class load happens only when it's actually needed. Now I don't see any reason why this Runnable is in #getPluginPreferences after all. Mark: Haha! How embarrassing, you were right :)

Plugin source code has a comment regarding this and it was clearly misleading:
// Performance: isolate PreferenceForwarder into
// an inner class so that it mere presence
// won’t force the PreferenceForwarder class
// to be loaded (which triggers Preferences
// plugin activation).

True, of course it makes sense that class load happens only when it’s actually needed.

Now I don’t see any reason why this Runnable is in #getPluginPreferences after all.

]]> By: Mark Hibberd http://ahtik.com/blog/2007/12/19/avoiding-useless-plugin-initialization-andor-class-loading/comment-page-1/#comment-108 Mark Hibberd Wed, 19 Dec 2007 19:03:47 +0000 http://ahtik.com/blog/2007/12/19/avoiding-useless-plugin-initialization-andor-class-loading/#comment-108 In what circumstances do you think that PreferenceForwarder will load from the first example <code> 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; </code> My understanding is that classloading on most JVMs is so lazy that it will only happen if the condition is evaluated to true. A few tests on different JVMs (Sun 1.4.2, 5, 6 and IBM 1.4.2, 6) with -verbose:class confirmed this behavior for me. It is not a big deal, but I am a little concerned with adding complexity (although not that much) for no reason. In what circumstances do you think that PreferenceForwarder will load from the first example

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;

My understanding is that classloading on most JVMs is so lazy that it will only happen if the condition is evaluated to true. A few tests on different JVMs (Sun 1.4.2, 5, 6 and IBM 1.4.2, 6) with -verbose:class confirmed this behavior for me.

It is not a big deal, but I am a little concerned with adding complexity (although not that much) for no reason.

]]>