LSP4E DeleteParticipant fails with FileSystemNotFoundException for custom EFS URI schemes

[StefanFu]

Environment:

LSP4E version: (0.19.13)
Eclipse: 2025-12
OS: Windows

Related to #1529

Description:

SP4E assumes that every Eclipse resource location URI can be converted into a Java NIO Path.

This is not true for resources backed by a custom Eclipse EFS (IFileSystem/IFileStore) using a non-file: URI scheme.

During a delete operation, LSPDeleteParticipant.initialize() calls

Path.of(resource.getLocationURI())

which throws

java.nio.file.FileSystemNotFoundException:
Provider "<scheme>" not installed

because Java NIO has no FileSystemProvider for the custom scheme.

Although the exception is caught by the LTK framework and the delete proceeds, LSP4E logs an error for every delete operation.
Stack Trace:

java.nio.file.FileSystemNotFoundException: Provider "libfs" not installed
at java.base/java.nio.file.Path.of(Path.java:213)
at org.eclipse.lsp4e.operations.rename.LSPFileOperationParticipantSupport.createFileOperationExecutor(LSPFileOperationParticipantSupport.java:120)
at org.eclipse.lsp4e.operations.rename.LSPDeleteParticipant.initialize(LSPDeleteParticipant.java:53)
at org.eclipse.ltk.core.refactoring.participants.RefactoringParticipant.initialize(RefactoringParticipant.java:108)
at org.eclipse.ltk.core.refactoring.participants.ParticipantExtensionPoint.getParticipants(ParticipantExtensionPoint.java:104)
at org.eclipse.ltk.core.refactoring.participants.ParticipantManager.loadDeleteParticipants(ParticipantManager.java:169)
at org.eclipse.ltk.core.refactoring.participants.ParticipantManager.loadDeleteParticipants(ParticipantManager.java:149)
at org.eclipse.ltk.internal.core.refactoring.resource.DeleteResourcesProcessor.loadParticipants(DeleteResourcesProcessor.java:314)
at org.eclipse.ltk.core.refactoring.participants.ProcessorBasedRefactoring.checkFinalConditions(ProcessorBasedRefactoring.java:240)
at org.eclipse.ltk.core.refactoring.CheckConditionsOperation.run(CheckConditionsOperation.java:87)
at org.eclipse.ltk.core.refactoring.CreateChangeOperation.run(CreateChangeOperation.java:116)
at org.eclipse.ltk.core.refactoring.PerformChangeOperation.run(PerformChangeOperation.java:208)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2505)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2533)
at org.eclipse.ltk.internal.ui.refactoring.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:90)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:123)

Steps to Reproduce:

1. Create an Eclipse plugin contributing a custom EFS implementation (org.eclipse.core.filesystem.filesystems).
2. Register a custom URI scheme (for example libfs:).
3. Create an Eclipse IResource whose getLocationURI() returns libfs:/folder/file.ext
4. Delete the resource using the standard Eclipse Delete action.
5. Observe the Error Log.

Expected

LSP4E should gracefully ignore resources whose URI cannot be converted to a Java NIO Path, or otherwise avoid using Path.of() for non-NIO URI schemes.

No exception should be logged.