Missing FileSystemProvider for the 'jdt' scheme

[fbricon]

vscode-java uses a custom URI scheme, jdt, to represent binary class files. However it only provides a TextDocumentProvider so jdt:// URIS can be opened as documents. Because vscode-java doesn't (yet) provide a FileSystem provider, vscode.workspace.fs.readFile calls on jdt URIs throw an ugly exception:

ENOPRO: No file system provider found for resource 'jdt://contents/java.base/java.lang/String.class?%3Ddemogorgon%2F%5C%2FUsers%5C%2Ffbricon%5C%2F.sdkman%5C%2Fcandidates%5C%2Fjava%5C%2F21.0.2-tem%5C%2Flib%5C%2Fjrt-fs.jar%60java.base%3D%2Fjavadoc_location%3D%2Fhttps%3A%5C%2F%5C%2Fdocs.oracle.com%5C%2Fen%5C%2Fjava%5C%2Fjavase%5C%2F21%5C%2Fdocs%5C%2Fapi%5C%2F%3D%2F%3D%2Fmaven.pomderived%3D%2Ftrue%3D%2F%3Cjava.lang%28String.class'

This affects Continue, see continuedev/continue#5536, which also impacts Granite.Code, see Granite-Code/granite-code#115.

vscode-java should provide a proper FileSystemProvider for the jdt scheme.

[rgrunber]

Based on https://github.com/microsoft/vscode/blob/a4f6aadf82df658fe63d4bc9bd2220f34a7927a2/src/vscode-dts/vscode.d.ts#L9539 this shouldn't be that bad. Everything except readFile and maybe stat are not going to do anything as class files should be read only. Looks like readFile is really the main one that needs to work.

Why wouldn't VS Code have a way for the filesystem API to fall back to the text document content provider in cases where that's the only thing defined ?

[fbricon]

Why wouldn't VS Code have a way for the filesystem API to fall back to the text document content provider in cases where that's the only thing defined ?

that's a question for the vscode team

[datho7561]

@MeherSru this might be interesting to do. I don't know how high impact it would be, but it seems like some parts of VS Code assume full filesystem support is added even if only text document content provider is provided. You'll have to take a look at the implementation here:

vscode-java/src/providerDispatcher.ts

Line 28 in ffbcf2d

const jdtProvider = createJDTContentProvider(options);

. Instead of a text document content provider, you'll need to register a filesystemprovider. The implementations of most of the methods should be empty outside of readFile and stat, since the content of the files is readonly. The readFile implementation should reuse the text document content provider implementation.