根据Eclipse文档的建议，我有一个编译每个源文件的org.eclipse.core.resources.IncrementalProjectBuilder，另外我还有一个可以编辑每个源文件的org.eclipse.ui.editors.text.TextEditor。每个源文件都被编译成自己的编译单元，但是它可以从其他(已经编译的)源文件引用类型。
这对于两个任务是很重要的:
- 正在编译(以确保我们使用的类型确实存在)
- 自动完成(查找类型，以便我们可以看到其中存在哪些属性/方法)
为了实现这一点，我想在内存中存储所有编译类型的表示(下面称为我的"类型存储")。
我的问题有两个:
-
上面的任务一由构建器执行，任务二由编辑器执行。为了使它们都可以访问这个类型存储，我是否应该在它们都可以访问的地方创建一个静态存储，或者Eclipse是否提供了一种更简洁的方法来处理这个问题?请注意，是eclipse，而不是我，在需要的时候实例化构建器和编辑器。
-
打开eclipse时，我不想为了重新填充类型存储而重新构建整个项目。到目前为止，我最好的解决方案是将这些数据保存在某个地方，然后从中重新填充我的商店(可能在项目打开时)。其他增量编译器通常是这样做的吗?我相信Java的方法是使用一个特殊的解析器来有效地从类文件中提取这些数据。
任何见解将是非常感激的。这是我第一次使用DSL
这是一个有趣的问题，而且没有一个简单的解决方案。我将尝试描述一种可能的解决方案，并更详细地描述JDT是如何完成增量编译的。
首先，简单介绍一下JDT:是的，JDT确实读取类文件来获取一些信息，但只读取没有源代码的库。这些信息实际上只用于编辑辅助(内容辅助、导航等)。
JDT通过跟踪编译单元之间的依赖关系来计算增量编译。此状态信息存储在磁盘上，并在每次编译后检索和更新。
作为一个更完整的例子，假设在完整构建之后，JDT确定A.java依赖B.java, B.java依赖C.java。
如果C.java中有结构变化(结构变化是可以影响外部文件的变化(例如，添加/删除非私有字段或方法))，则B.java将被重新编译。A.java将不重新编译，因为B.java中没有结构变化。
在澄清了JDT的工作原理之后，这里有一些可能的答案:
- 是的。这必须通过静态可访问的全局对象来完成。JDT通过JavaCore和JavaModelManager对象实现这一点。如果你不想使用全局单例，那么你可以通过插件的Bundle activator实例访问你的类型存储。e4项目确实允许依赖注入，这可能更好(但并不是Eclipse核心api的一部分)。我认为在文件系统上持久化信息是最好的选择。确定增量编译依赖的唯一真正方法是执行完整构建，因此需要将信息保存在某个地方。同样，JDT就是这样做的。该信息存储在您的工作空间的
.metadata目录某处在org.eclipse.core.resources插件。您可以查看org.eclipse.jdt.internal.core.builder.State类来查看实现。
所以，这可能不是你想要的答案，但我认为这是最有希望解决你的问题的方法。