Java内存中的文件结构？
我需要动态地使用资源做很多事情：解析 xsd/xml 文档、构建和编译 java 类、将它们打包到 jar 和 wars 中、保留在 DB 中、将它们部署为 OSGi 等。
大多数库/API我使用的，允许在内存中执行所有这些中间任务，但是有一些“特殊”库仅使用 java.io.File 进行操作。除了使用真正的临时文件和目录之外，我别无选择，这在 Java EE 环境中并不好。
我相信必须有一个内存文件结构的库/解决方案，其节点扩展java.io.File（正如我所见）。请添加已知/类似库的链接。欢迎任何评论。
谢谢！
I need to do a lot of things with resources on the fly: parsing xsd/xml docs, building and compiling java classes, package them into jars ans wars, persist in DB, deploy them as OSGi, etc.
Most of the libraries/API's, which I use, allow to perform all these intermediate tasks in memory, but there are some "special" libraries operating with java.io.File only. And there's nothing left for me but using real temporary files and directories which is not good in Java EE environment.
I believe there must be a library/solution for in-memory file structure having nodes extending java.io.File (as I see it). Please drop in a link to known/similar libraries. Any comments are welcome.
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我不相信你会找到你想要的东西。 java.io.File API 的编写目的并不是为了提供可以通过多种方式实现的文件系统抽象。虽然它确实公开了某些 FS 操作（例如删除和 mkdir）的方法，但它不处理基本的读/写 I/O。这留给其他类，例如 FileInputStream。这意味着从 API 的角度来看，File 对象只不过是一个路径。没有什么是抽象的。你被困住了。
I do not believe you are going to find what you are looking for. The java.io.File API was not written with the intention of providing a file system abstraction that can be implemented in a variety of ways. While it does expose method for some FS operations (such as delete and mkdir), it doesn't handle the basic read/write I/O. That is left to other classes, such as FileInputStream. This means that from API standpoint, a File object is no more than a path. Nothing is abstracted. You are stuck.
一种选择是使用 RAM 磁盘。您的程序会认为它使用带有 java.io.File 的磁盘，但它实际上会使用主内存。
One option is to use a RAM disk. Your program will think its using the disk with java.io.File, but it will really be using main memory.
有一个很好的替代方案： https://github.com/google/jimfs
这支持 java( 7+）内存文件系统处理并且也非常易于使用。
There is a fine alternative available: https://github.com/google/jimfs
This supports java(7+) in memory filesystem handling and is very easy to use too.