We are migrating our Eclipse-based integration from SonarLint 10.x to SonarLint 11.x.
Our application works with mainframe COBOL source members stored in z/OS PDS/Datasets. These files are accessed through an Eclipse EFS provider and are exposed as Eclipse IFile resources. They are not local filesystem files and are not part of a Git repository.
With SonarLint 10.x, analysis works correctly.
After upgrading to SonarLint 11.x, analysis starts but fails with the following exception:
java.nio.file.FileSystemNotFoundException: Provider “zosfs” not installed
From debugging, it appears that SonarLint 11 passes the zosfs:// URI into the backend process, where BackendInputFile.getPath() calls Path.of(uri). Since the backend JVM does not have a Java FileSystemProvider for the zosfs scheme, Path.of() throws FileSystemNotFoundException.
Has the handling of Eclipse EFS-backed resources changed between SonarLint 10.x and 11.x?
Is SonarLint 11.x expected to support analysis of Eclipse IFile resources backed by non-file:// URI schemes (such as mainframe datasets), or is there a recommended approach for Eclipse plugins to provide these resources for analysis?
This is a known limitation tracked internally in this development ticket. However it was canceled last year due to the complexity and low interest in the feature.
The FileSystemNotFoundException: Provider 'zosfs' not installed occurs because when SonarLint’s backend (which runs as a separate JVM process) tries to resolve a non-file:// URI to a java.nio.file.Path, the custom filesystem provider (zosfs) registered in Eclipse’s JVM is not available in the backend process, they’re separate runtimes.
A couple of questions that would help:
Are you on SonarLint for Eclipse 11.x, or specifically which version? Could you test with the latest (12.3) to see if the behavior changes?
When the exception is thrown, does analysis fail entirely, or do you still get some results with errors logged?
SonarLint 10.0.1 works correctly in our environment.
Starting from 10.2 (I believe the architectural changes were introduced after 10.2), I see the same issue.
I also tested with 12.4, and the behavior is unchanged.
FYI, I have already updated the deprecated SonarLint APIs to the newer APIs introduced after 10.2.
However, after upgrading:
Some options, such as Analyze Changed Files, are missing.
The available analysis options do not work correctly.
Analysis fails entirely.
For example, when running Analyze, we get:
java.nio.file.FileSystemNotFoundException: Provider “zosfs” not installed
Our resources are mainframe COBOL members exposed as Eclipse IFile resources through an Eclipse EFS provider (zosfs://), so this prevents analysis from completing successfully.
We have tried all the possible approaches from our end to resolve this issue, but unfortunately, we have not been able to identify a solution.
Could you please help us with any suggestions, guidance, or inputs that might help resolve this issue?
Additionally, could you let us know if there is an estimated timeline for a fix? If someone else is better suited to assist with this, we would appreciate it if you could share their contact details or direct us to the appropriate person.
At the moment, we are unable to use this functionality for our online projects, and it is impacting all of our users. We would appreciate any assistance you can provide.
First of all, the development ticket mentioned (SLE-607) does not fully match the issue here; it was also me who closed that ticket at some point The details and differences are a bit more nuanced on the technical side here.
The behaviour changed with SLE 10.2, as then the architecture from that plug-in moved from being fully in the Eclipse IDE environment (also relying on the Eclipse IFile logic completely) to being split into a frontend part (running in the IDE) and a backend process, as mentioned by Steven.
Since after that, other (or similar, I can’t recall when I was still developing the plug-in) issues arose with COBOL IDEs, there were already fixes in place provided by the COBOL IDE developers.
Would you be so kind as to please also provide the information about the COBOL IDE you have (vendor, name, version)? I would guess it is some version of IBM Developer for z/OS.
The only idea I currently have that comes to mind as well would be to always resolve a file (or path and possibly re-construct the file object) to an absolute path on disk (what the zosfs:// provider is basically doing; it is proprietary tho) before it is handed to the backend process.
But even with the COBOL IDE, without access to a system with zosfs:// resolution, this is not really possible to test, I recall.
If you need some help or some info from the back of my mind, don’t hesitate to reach out.
I cannot really give you any other guidance or suggestions besides the information provided above, sorry.
The details and differences are a bit more nuanced on the technical side here.