路径|和 .project 文件说“再见”—— VS Code Java 1.1.0 背后的故事( 三 )


因此 , 这一次我们直接从 Eclipse 底层文件系统入手分析 , 并最终发现了一枚解决问题的“银弹”:File System Provider 和 FileStore(注:虽然在软件工程领域 , 人们的共识是没有银弹 , 不过对于这一特定的问题 , 我们确实找到了一种比较“奇巧”的解决办法) 。

  • 银弹: https://0x9.me/EGhKL
  • 软件工程: https://0x9.me/x8cAy
Eclipse 工作空间结构与 FileStore
Eclipse 在运行过程中会为整个工作空间维护一颗 树形结构 , 树的节点代表了文件系统中的文件或目录 , 同时还保存了文件的一些重要信息 , 如修改时间等 。
Eclipse 底层通过 FileStore 类将这些节点和文件系统中的文件进行关联 。 FileStore 类还有一个重要特性:如果映射的对象是单个文件 , 那么 FileStore 还会负责提供这一文件的输入输出流 。
这一特性为问题的解决带来了非常重要的思路:只要能够将元数据文件的输入输出流重定向到项目目录之外的位置 , 问题也许就能得以解决 。 带着这个假设 , 我们又发现了另一个关键线索:File System Provider 。
  • 工作空间结构: https://0x9.me/0o8nL
  • 树形结构: https://0x9.me/sw4Ga
方案三
File System Provider
File System Provider 是 Eclipse 平台对外开放的一个扩展点 , 它允许开发人员实现一个 Eclipse 文件系统接口(org.eclipse.core.filesystem.IFileSystem) , 并将其注册到扩展点上 , 用以处理具有特定 URI scheme 的文件请求 。
于是我们从 File System Provider 这一拓展点入手 , 继承并覆盖了 Eclipse 默认处理 URI scheme 为 file 的文件系统 , 通过覆写其中的一些方法 , 让文件系统在处理元数据文件时 , 将文件路径重定向到项目路径之外的地方进行读写 。 相比于方案二 , 这一套方案的优点在于:
  • 对其他模块完全透明, 基本不需要进行修改就能正常工作 , 这同时还意味着较好的 拓展性。
  • 代码量很小, 最终的实现 , 算上 JavaDoc 和注释 , 一共只有 300 行左右 。
当然这个方案也并非完美 , 因为它要求其他模块通过 Eclipse 提供的 API 进行对元数据文件的读写操作 。 我们在实现过程中就发现上游 Buildship 在 处理元数据文件时直接通过 JDK 中的文件 I/O API 进行读写 , 为此我们提交了一份 变更请求将相关操作迁移到了 Eclipse API 上 。
  • 处理元数据文件时直接通过 JDK 中的文件 I/O API 进行读写: https://github.com/eclipse/buildship/issues/1111
  • 变更请求: https://github.com/eclipse/buildship/pull/1114
总结

路径|和 .project 文件说“再见”—— VS Code Java 1.1.0 背后的故事
文章图片


路径|和 .project 文件说“再见”—— VS Code Java 1.1.0 背后的故事

推荐阅读