最新的vs code java扩展组件1.1.0版本，在扩展组件导入新的java项目时，将不会在项目默认路径中，生成项目的元数据文件，包括.project、.classpath和配置等，免去用户在浏览文件，以及git管理程序代码版本时所产生的麻烦。
这个问题要追溯到2018年开发者，在github上提出的问题，该贴文描述到，当使用vs code的java扩展组件打开java项目时，无论是maven还是gradle，扩展组件都会在项目资料中创建许多.project、.settings或.classpath等文件，贴文作者表示，他必需要把这些文件添加到.gitignore文件中，还要把他们加入到vs code配置中的files.exclude，才能在资源管理器中隐藏。
java扩展组件因为导入项目时，会在项目目录下产生元数据文件的这个问题，获得许多一星评价，随着java扩展组件功能越来越多，扩展组件使用的人数也稳定增加，影响范围扩大，微软决定再次尝试解决这个问题。微软提到，并不是他们的产品团队不想解决这个问题，但这个问题根本原因在于java语言服务的架构，使他们难以施力。
vs code java扩展组件使用一个称为eclipse jdt language server，由微软和红帽共同开发的java语言服务项目，而jdt language server使用了部分eclipse模块，这些烦人的元数据文件，便是由这些上游模块产生，因为这些元数据文件的路径，在实例过程在程序代码中都写死成常数，且已经被各种eclipse模块和扩展组件参照，所以俨然成为多年的技术债。
考虑到改变上游模块的行为，可以能对下游项目产生许多不确定性，微软过去尝试了一些方法，像是在vs code文件浏览器中，隐藏这些元数据文件，并引导用户添加到.gitignore，不过显然用户并不买单这个做法，因此经过了三年，微软再次进行多项尝试，希望能够找到更好的九游会官网真人游戏第一品牌的解决方案。
微软尝试了符号连接（symbolic link）以及eclipse连接资源（eclipse linked resources）解法，但都因为各种限制不尽理想，最后的解法则是使用文件系统提供程序（file system provider）。微软解释，文件系统提供程序是一个eclipse平台的扩展点，能让开发者实现eclipse文件系统接口，并将其注册到扩展点，以处理特定uri架构的文件请求。
微软从文件系统提供程序扩展点下手，继承并复写eclipse默认的文件处理系统，通过复写其中一些方法，文件系统在处理元数据文件时，会重定向文件路径，并且读写文件到项目路径之外的地方，这项解法的优点是，对其他模块透明，不需要修改就可以正常运行，程序代码变动量也很小，最终实例只改动300行左右的程序代码。
虽然这项做法还是有其缺点，其他模块需要通过eclipse api来读取元数据，不过和别的方法比起来，从文件系统提供程序着手是最不复杂，且最适当的方法，终于解决了这个困扰用户三年多的问题。