Renaming modified src.java file leads to Cannot save src.java error. Hotfix.

[JaroslavTulach]

Using VSNB ext 12.2.252 and GraalVM 21.1.0 JDK8 CE build.

• Create Micronaut App project - see wiki
• Click icon in Explorer to add file, name it e.g. "HellController.java"
• paste in content for HelloController.java sample.
• Rename the file in VSCode explorer to "HelloController.java"
• VSNetBeans complains file was changed on disk and has to be reloaded.
• Check the PROBLEMS window in VSCode it still lists "HellController.java" as having improperly named class.
• Press F5 for debugging the project it prints to console :

        Info: Saving HellController ...
        Info: Save All finished.
        and dialog appears with "Cannot save HellController" message from VSNB ext

• Close the folder with project and open again and it starts behave correctly

The PR workarounds the problem by not showing the "complains file was changed on disk and has to be reloaded". There may be better fixes, especially when lsp4j starts to fully support 3.16 protocol which contains notifications like willRename/didRename.

[sdedic]

Hotfix OK.
I vaguely thought about some "Environment"-like strategy pluggable into Loaders or Filesystems that would define strategy for files/dobjs synchronization. But most probably more data still needed on what are the behaviours that need to be 'externalized' when NB is used just as a helper.

[JaroslavTulach]

I vaguely thought about some "Environment"-like strategy pluggable into Loaders or
Filesystems that would define strategy for files/dobjs synchronization.

There is a clash between global/environment-like solution and local solution. Only DataEditorSupport knows what it wants exactly to do when a file is changed. That's the local knowledge. I am afraid you'd need many pluggable strategies for each individual case.

The best way to implement the global/environment solution is to replace current implementation of FileSystem (e.g. masterfs) with another one that would be tighter integrated with VSCode workspaces concept.

strategy for files/dobjs

The important difference between FileObject and DataObject in this case is identity. When a FileObject is moved or renamed, it changes identity. Moving or renaming DataObject keeps the identity. To match VSCode/NetBeans concepts when renaming an open and modified editor, it would be desirable to keep DataObject's identity - that's not the case right now.