CODEWITHSUNDEEP
javafile-ioramfileinputstream
Matt
Matt

Reputation: 375

Launch a file created in RAM memory

I've been asked to launch an Excel file, created at RunTime inside the RAM memory.

For example, with:

Desktop.getDesktop().open(new File("c:\....\fileName.xlsx"));

I can "launch" Excel program that open the file "c:....\fileName.xlsx".

Since my file is created inside the RAM memory this way:

 ...

     FileSystemManager fsm = VFS.getManager();
     FileObject RAM = fsm.resolveFile("ram://ramFileName.xlsx");
     OutputStream os = RAM.getContent().getOutputStream();
     FileInputStream sorgente = new FileInputStream("C:\\originalFile.xlsx");   
     int singloByte;

     while ((singloByte = sorgente.read()) != -1) {
        os.write(singloByte);
     }
     sorgente.close();
     os.close();
     ...

is there a way to open a file created only in RAM memory and not in file system?

Thank you

Upvotes: 2

Views: 430

Answers (2)

Stephen C
Stephen C

Reputation: 718768

@Kayaman's answer is correct (nearly).

Since Excel can't open "in-memory files" (AFAIK) ...

is absolutely correct, if we are talking about a Java VFS "ram:" file system.

Firstly we need to understand the difference between a normal file system and a Java VFS.

A normal file system is one that the operating system supports. An application accesses a normal file system by making system calls (open, read, write, seek, opendir, etcetera) that cross the user-space to kernel-space boundary. The kernel may deal with the request in different ways depending on the file system type; e.g. NFTS, FAT, a mounted SMB share, etcetera. Or in some operating systems, the requests may be passed to a user-space file system; e.g. a loop-back file system where a ISO image or a ZIP file is mounted as a file system.

The key thing about a normal file systems is that the application sees them all (pretty much) the same, and accesses them using standard syscalls.

By contrast, a Java VFS is an abstraction where the common API is implemented by the Java library rather than by the operating system. For example, a Java read(...) method call for a stream will be mapped to a call on the VFS object. This may be dispatched to a real file system (via a syscall), or to a virtual file system implemented within the JVM. A "ram:" VFS could be represented using memory allocated from the Java heap or the native heap.

The Excel application is a native application. Native applications can talk to normal file systems, in the same way that a Java application would; via the syscalls. But since it the Excel application is not running within the address space of the JVM that holds your "ram:" VFS, there is no way that it can access it.

But that's not the end of the story. There are a couple of ways that you could get Excel to read from an in-memory file.

Some operating systems support a "normal" file system that lives in RAM ... or virtual memory. For example, a typical Linux system will use a "tmpfs" file system to hold the "/tmp" directory. So, on Linux you could arrange for your Java application to write files into a "tmpfs" file system, and then pass the pathname to an application like Excel. On Windows, I think you need to use 3rd-party RAM disk software; see the following page:

The second approach is more complicated. I mentioned above that SMB network shares are accessed as "normal" file systems. SMB is actually a network protocol that allows a client (your local operating system) to access files on the SMB file server. Now it is at least theoretically possible for a Java application to implement the server-side of the SMB protocol, and use its heap to store the "files" that it serves up to a client. So ... hypothetically ... you could start your SMB-server-in-a-Java-application, and then get the operating system to mount it as a network share. Then your Excel application could read and write files from the Java application's memory via the share.

I wouldn't call that a practical approach (unless you have deep pockets!), but I know of a Java-based platform that does do this kind of thing; exposing its "repository" to clients via its own Java implementations of the NFS, S3 and other protocols.

Upvotes: 3

Kayaman
Kayaman

Reputation: 73538

Excel files can't be "launched". What Desktop.open() does is finds the default handler for the file (presumably Excel in this case), and launches the handler with the given file as a parameter.

Since Excel can't open "in-memory files" (AFAIK), you have no choice but to write it to a temporary file to open it.

Upvotes: 2

Related Questions