redhat-developer
Missing FileSystemProvider for the 'jdt' scheme
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 https://github.com/continuedev/continue/pull/5536, which also impacts Granite.Code, see https://github.com/Granite-Code/granite-code/issues/115.
vscode-java should provide a proper FileSystemProvider for the jdt scheme.
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 ?
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