An in-memory file system for Java implementing java.nio.file APIs, useful for testing and simulation.
Jimfs is an in-memory file system implementation for Java that provides a complete simulation of the java.nio.file APIs. It allows developers to perform file operations like reading, writing, and directory management entirely in memory, without interacting with the physical disk. This solves the problem of needing a controllable and isolated file system for testing, debugging, or simulation scenarios.
Java developers who need to test file system operations in unit tests, integration tests, or simulations without relying on the host file system. It's particularly useful for those building applications with complex file I/O logic.
Developers choose Jimfs because it offers a lightweight, fast, and fully-featured in-memory file system that closely mimics real file system behavior. Its support for the standard java.nio.file APIs means existing code can be tested with minimal changes, and its configurability allows simulation of different platforms like Unix or Windows.
An in-memory file system for Java
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Implements almost all java.nio.file APIs, including advanced features like symbolic links and WatchService, ensuring seamless integration with existing file operation code.
Supports Unix or Windows-style paths and behavior via Configuration.unix() or .windows(), allowing tests to mimic different operating environments without real disk access.
Runs entirely in memory, providing fast execution and complete isolation from the host file system, which eliminates disk I/O overhead and ensures test repeatability.
Available via Maven Central with a straightforward API, as demonstrated by the simple Jimfs.newFileSystem() call in the README's basic use example.
File permissions can be set via attribute views like 'posix', but they do not enforce access control, making it unsuitable for security or permission-based testing.
While configurable, behavior is modeled after UNIX and may not exactly match all real file system specifics, especially for Windows-dependent applications.
Lacks persistence, so data is lost when the FileSystem is closed, and large-scale tests can lead to high memory usage, limiting stress testing scenarios.