路径|和 .project 文件说“再见”—— VS Code Java 1.1.0 背后的故事( 三 )
因此 , 这一次我们直接从 Eclipse 底层文件系统入手分析 , 并最终发现了一枚解决问题的“银弹”:File System Provider 和 FileStore(注:虽然在软件工程领域 , 人们的共识是没有银弹 , 不过对于这一特定的问题 , 我们确实找到了一种比较“奇巧”的解决办法) 。
- 银弹: https://0x9.me/EGhKL
- 软件工程: https://0x9.me/x8cAy
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 行左右 。
- 处理元数据文件时直接通过 JDK 中的文件 I/O API 进行读写: https://github.com/eclipse/buildship/issues/1111
- 变更请求: https://github.com/eclipse/buildship/pull/1114

文章图片

推荐阅读
- 星链|石豪:在太空,马斯克和美国当局是如何作恶的
- 下架|APK Installer 和 WSATools 同时躺枪:冒牌应用登陆微软应用商店
- 软件和应用|AcrylicMenus:让Windows 10右键菜单获得半透明效果
- 技术|使用云原生应用和开源技术的创新攻略
- 软件和应用|iOS/iPadOS端Telegram更新:引入隐藏文本、翻译等新功能
- 实力比|小米12对标苹果遭嘲讽?雷军:国产手机的实力比想象中强,有和苹果比较的勇气
- Apple|法官称苹果零售店搜包和解协议虽不完美,但可继续进行
- 部落|excel固定显示行列视频:应用冻结窗格同时固定标题行和列
- 最新消息|宝马LG和其他公司正考虑使用量子计算机解决具体问题
- 通信运营商|英国沃达丰、EE和Three将在2022年一同恢复欧盟漫游费用