用 Runtime Syp 调整 Eclipse 的启动性能，第 2 部分：成功的骗局

核心提示： 注意对 <action> 标签的 class 属性的处理，这指定了将来处理菜单选项选择的类的名字，用 Runtime Syp 调整 Eclipse 的启动性能，第 2 部分：成功的骗局(10)，这个类必须实现 IWorkbenchWindowActionDelegate 接口，这个类

注意对 <action> 标签的 class 属性的处理。这指定了将来处理菜单选项选择的类的名字，这个类必须实现 IWorkbenchWindowActionDelegate 接口。这个类并不位于处理 org.eclipse.ui.actionSets 扩展点的同一个插件中（Workbench UI 插件），也不位于它的先决插件中。那么，当它看起来不取决于插件的 classpath 时，Workbench UI 插件如何去创建这个类的一个实例呢？

插件的类加载器 (classloader) 负责在它的库中解析对类的引用。类加载器将插件引用映射到它们相应的包含有插件类的 JAR 文件，比如我们的例子， SampleAction 。因此，Workbench UI 插件不必“知道”通过属性引用的类，比如 <action> 标签的 class 。相反，是由于“Hello Eclipse”插件定义了对 Workbench UI 插件的依赖而使之可以访问目标插件的类，因而有权通过目标插件的类加载器访问 Hello Eclipse 的类。简洁地重述一遍，当 Eclipse 找不到某个类时，它会要求目标插件的类加载器去加载那个类；那就是 createExecutableExtension 方法所做的事情。

避免与扩展点处理相关的过早的插件激活

回到图 8 中所示的栈记录，我们可以发现，在所选择的文本中部的代码通过调用 createExecutableExtension 对扩展贡献进行处理 —— 看吧! 插件开始加载了。我们现在要寻觅的是明摆着的问题的答案：这时需要加载它吗？可以将它的加载向后延迟吗？

实际上所有会激活另一个插件的类最终都可以追溯到对 createExecutableExtension 方法的调用。这些调用的调用参数指明了属性名（通常是 “ class ”）和它的值，即要加载的类的全名。这就带我们回到了导致激活（此插件）的插件扩展贡献，在我们的例子中也就是 subuilder 插件。清单 2 是它的清单的摘录。