Можно ли создать виртуальный диск Java для использования с API java.io.*?

Итак, есть ли способ зарегистрировать RAM-диск в Java, который можно было бы использовать со стандартным API java.io.*?

Не с Java 6 или более ранней JVM. Java 6 и более ранние версии не предоставляют SPI для регистрации файловых систем или типов файловых систем. Таким образом, реализация RAM FS, которую приложение будет использовать как обычную FS, повлечет за собой изменение поведения ряда java.io.* классов.

Я думаю, что лучшее, что вы могли бы сделать, это использовать RAM FS, реализованную операционной системой хоста. Вы должны иметь доступ к этому из Java, как если бы это была обычная файловая система. Однако ввод-вывод повлечет системные вызовы, поэтому он будет не таким быстрым, как если бы файловая система RAM находилась в управляемой памяти JVM.

Теоретически Стивен прав. Но я могу предложить вам хитрость. Вы можете реализовать свои собственные FileInputStream и FileOutputStream и поместить их в bootclasspath. Ваша реализация, например, будет реализовывать open(), read() и readBytes() (которые являются собственным методом в обычном FileInputStream.)

Это чистое Java-решение для вашей проблемы. Его недостаток в том, что вам нужно запускать свои тесты в отдельном экземпляре JVM.

Основная проблема, которую вы пытаетесь решить, заключается в том, что исходные java.io API совсем не гибкие (все они относятся к конкретным классам). Единственный способ добавить другую функциональность, например java.io.File, — это расширить базовый класс.

Расширение классов после того, как они разработаны, может быть плохим дизайном (просто посмотрите на класс Properties) - поэтому вы, вероятно, не найдете библиотеку, которая делает это.

Ничто не мешает вам расширить класс java.io.File самостоятельно, а все методы проксировать, например, на FileObject Commons VFS API.

Изменить. Тем не менее, есть вещи, которые, вероятно, не сработают при таком подходе, например, использование конструкторов File, принимающих родительский элемент File.

Правка 2. Я бы начал примерно так:

public class VirtualFile extends java.io.File {
    public static VirtualFile fromFile(File file) {
        if (file instanceof VirtualFile) {
            return (VirtualFile) file;
        } else {
            FileSystemManager fsm = new DefaultFileSystemManager();
            return fsm.toFileObject(file);
        }
    }

    private final org.apache.commons.vfs.FileObject mProxyFileObject;


    public VirtualFile(FileObject proxy) {
        super("/tmp/xxxx"); // That part needs some work to be cross-platform.
                            // However, such a construction will completely
                            // destroy the expectations that other classes 
                            // have about what a File is.
        mProxyFileObject = proxy;
    }

    public VirtualFile(VirtualFile parent, String child) {
        this(parent.mProxyFileObject.resolveFile(child));
    }

    public VirtualFile(File parent, String child) {
        this(fromFile(parent), child);
    }

    @Override
    public boolean canExecute() {
        throw new UnsupportedOperationException();
    }

    @Override
    public boolean canRead() {
        try {
            return mProxyFileObject.isReadable();
        } catch (FileSystemException fse) {
            // FileSystemException is not a Runtime Exception :(
            throw new RuntimeException(fse);
        }
    }

    // Override ALL public methods to throw Exceptions; 
    // implement or mock only the methods that you need.
}

Что касается того, почему конструктор File(File, String) не будет работать с такой настройкой: этот конструктор не ожидает, что реализация File нарушит контракт класса, что мы и делаем, когда вызываем super("/tmp/xxxx"). (И мы не можем избежать нарушения контракта класса, потому что виртуальные файлы, с которыми мы хотим работать, не имеют простого File эквивалента)

Итак, вот и все — это потребует нетривиальной работы, и есть значительный шанс, что библиотека все равно не будет работать так, как ожидалось.