FileSystemMap：与文件系统交互的自然方法

作为项目的一部分，我目前正在研究创建FileSystemMap 。我已经开始了一个非常小的GitHub的项目在这里举办的代码。

本质上，此映射实现将允许用户与其文件系统上的目录进行交互，就好像它是java.util.Map 。映射中的每个条目将是该目录中的文件，键将是文件名，值将是文件的内容。

此代码构建一个FileServiceMap并添加五个条目：

Map map = new FileSystemMap("/tmp/filetests");map.put("one", "one");map.put("two", "two");map.put("three", "three");map.put("four", "four");map.put("five", "five");

这将导致直接的结构如下：

/tmp/filetests/|----- five|----- four|----- one|----- three|----- two

添加和删除条目将更改目录中的文件。更改条目的值将导致使用新值作为内容重写文件。有关更多示例，请参见testMapMethods中的代码。

此外， FileSystemMap已设计用于双向交互。对其进行的任何程序性更新都将反映在文件系统上，并且对文件系统的任何更新将由地图拾取并作为事件触发。

此代码将更改注册到文件系统并打印出来：

Map map = new FileSystemMap("/tmp/filetests");
map.registerForEvents(System.out::println);

这是一些示例输出：

FPMEvent{eventType=NEW, programmatic=true, key='one', value='one'}

eventType是以下之一：

新–文件已创建
更新–文件已被修改
删除–文件已被删除

编程标志指示是否触发事件的是FileSystemMap本身。例如，如果调用了put() ，将创建一个文件，该文件又将引发一个事件。为了避免反馈，了解它是否是触发事件的FileSystemMap上的操作可能很有用。

密钥是已更改文件的名称。

该值是与已更改文件关联的最新值。 注意：这可能是也可能不是实际触发更改的值 。例如，如果条目有两个非常快速的更改，则在第二次更新已经发生之后，第一个事件的值完全有可能会获得该值。例如

map.put("one", "1");map.put("one", "2");

可能产生以下输出：

FPMEvent{eventType=NEW, programmatic=true, key='one', value='2'}

拾取了第一个事件（通过将“ one”设置为“ 1”触发），但是在程序检查文件内容时，文件已更改为“ 2”。然后拾取第二个事件（通过将“ 1”设置为“ 2”来触发），但是由于该值未更改，因此将其抑制。

一些注意事项：

以“。”开头的文件。被忽略。原因是许多编辑器（包括vi）创建的临时文件不应由FileServiceMap拾取。
如果查看代码，您会注意到WatchService（自Java7开始）用于监视对文件系统的更改。重要的是要了解WatchService是特定于操作系统的。特别是在Mac OSX上，它不能很好地工作。该主题讨论了一些问题。 WatchService的更新速度很慢，可以丢弃快速流动的事件。在我的测试中，Ubuntu的性能明显优于MacOSX。但是，如果您主要对手动执行的文件系统更改感兴趣，那么Mac OSX也可以。
映射仅支持字符串。

不用说，此类是为特定的实用程序而不是任何性能而设计的。

欢迎对该项目的所有贡献！