Implementing FileSystem without MANIFEST.MF/META-INF/services

I'm trying to set up a file system (by implementing FileSystemProvider, FileSystem, FileStore, etc.) so that later a user could only call FileSystems.getFileSystem(uri), with a specific URI (custom scheme, host, path, etc).

This is normally done by putting an entry into jar's MANIFEST.MF/META-INF/services, so that a JVM - using that information - can set it up itself, but I don't have that option. I want to do it programmatically. How can this be done?

Did you try Google with this: java.nio.file.spi.DefaultFileSystemProvider

Quote:

---

Originally Posted by Norm

Did you try Google with this: java.nio.file.spi.DefaultFileSystemProvider

---

I did. But following virtually every found page/document I end up with "Providers are typically installed by placing them in a JAR file on the application class path or in the extension directory, the JAR file contains a provider-configuration file named java.nio.file.spi.FileSystemProvider in the resource directory META-INF/services" or words to that effect.

Like I said, I don't have that option. I want to

1. implement my own FileSystemProvider (and everything else it needs) and then
2. give it to JVM's disposal in such a way that a user could later
3. obtain instances of FileSystem it produces through FileSystems.newFileSystem(URI, ...) and FileSystems.getFileSystem(URI, ...).

I just don't know how to do #2. I'd like to know if it's possible and - if it is - how it can be done.

BTW: I don't really want to displace DefaultFileSystemProvider by setting system property, if that's what you meant. The FileSystem I need doesn't have much with disks (as in "file://" scheme/protocol). Think of it more like a set of distributed sources of data, including database(s) and network(s).

What about Jimfs?

Quote:

---

Originally Posted by Norm

What about Jimfs?

---

I would gladly use anything that would help me achieve the three points I described above. I can't seem to make that connection (using Jimfs facilities to make FileSystems.getFileSystem(URI) produce the FileSystem I need/implement). Would you help me with that, please? I don't mean implementing. Pointing me in the right direction would do. Thanks.

I've never written a FileSystem for java. I did write one for an IBM OS a long time ago and have an interest in how to do it for java.

The code for the jimfs system is on github. Download it and take a look at how it works.

Quote:

---

Originally Posted by Norm

I've never written a FileSystem for java. I did write one for an IBM OS a long time ago and have an interest in how to do it for java.

The code for the jimfs system is on github. Download it and take a look at how it works.

---

In Java, FileSystem is merely an abstract class one has to extend to make it suit ones own needs. It's a pretty high level abstraction of a file system. Implementing it is trivial in comparison with a low level stuff one has to do to implement a file system from hardware stand point, like I suspect you did.

I have taken a look at Jimfs, even before you had mentioned it. But I don't think it can meet my needs (I could be wrong, though). Like I said, I know how to implement FileSystemProvider, FileSystem, FileStore(s), etc. I just don't know how to seamlessly integrate it (the provider I mean) into a JVM so that the users could use it with no extra plumbing on their side, merely calling FileSystems.getFileSystem() with a proper URI.

Quote:

---

users could use it with no extra plumbing

---

I'm not sure how that would work. If the user doesn't tell the JVM about your URI, when and how would the JVM learn about it?

Quote:

---

Originally Posted by Norm

I'm not sure how that would work. If the user doesn't tell the JVM about your URI, when and how would the JVM learn about it?

---

User in a sense of a client. There is a platform, providing services incl. instances of FileSystem through FileSystems factory methods (FileSystems.getFileSystem(URI)) and there are clients on top of that platform. All the client needs to know is a correct URI. The data is then supplied to the clients using instances of FileSystem.

The platform would somehow register my implementation of FileSystemProvider and FileSystem (plus the URI specs) with the JVM, so that users (clients) would then be able to obtain them through FileSystems.getFileSystem(URI). At first I thought that this could be done through ServiceLoader, but then I realized that ServiceLoader relies on META-INF/services (inside jars) and only loads what is specified there.

What about the java -D option?

Quote:

---

Originally Posted by Norm

What about the java -D option?

---

What about it? That's an equivalent of setting a system property, right? Which property do you have in mind? And why?

Have you looked at what the JVM does with the jar's MANIFEST.MF/META-INF/services entries?

I'm a bit confused about where you'd put your code for the new file system. Using a jar file with the services folder seems like a convenient place.

Quote:

---

Originally Posted by Norm

Have you looked at what the JVM does with the jar's MANIFEST.MF/META-INF/services entries?

---

No, I haven't. I don't know where to look.

Quote:

---

Originally Posted by Norm

I'm a bit confused about where you'd put your code for the new file system. Using a jar file with the services folder seems like a convenient place.

---

It does, doesn't it. Well, I hate to repeat myself but... I don't have that option.

Quote:

---

I don't have that option.

---

Can you explain what the problem is with using that option?

Quote:

---

where to look.

---

Google.
The src.zip file that comes with the JDK.

I still wonder
where your code would be physically when its used
and what would make the JVM execute your code.

I've given up on trying to register a FileSystemProvider so that it could deliver instances of FileSystem through FileSystems.getFileSystem(URI).

I've settled for a semi-workaround, though: using FileSystems.newFileSystem(URI, Map<String,?>, ClassLoader). Of course that means that I need a way to pass the required ClassLoader around. I'm looking for something like a System.setProperty() and System.getProperty() but for Object/ClassLoader values instead of Strings. I would use the setter to "register" the ClassLoader and the user/client would use the getter to obtain it and use it to create the FileSystem.

What would you recommend?