You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, external class files are (when the user requests a "Go-To-Definition") decompiled into a temporary file on disk and transferred to the client by referencing the corresponding file URI. Temporary on-disk resources depend on a cleanup hook, which may or may not run, depending on whether the language server process is forcefully terminated.
Similar to how the Java language server does this, it might be cleaner to have a custom URI scheme for resources inside JAR files. For example, replacing:
Ensuring that the client supports these URIs (e.g. by registering a capability) and otherwise falling back to temporary files
Having to maintain a non-standard LSP request under which the language server can dynamically serve the text content of these temporary resources (JDT.LS calls this java/classFileContents)
fwcd
changed the title
Investigate using a custom URI scheme for decompiled *.class resources
Investigate a custom URI scheme for decompiled *.class resources
Aug 6, 2019
Currently, external class files are (when the user requests a "Go-To-Definition") decompiled into a temporary file on disk and transferred to the client by referencing the corresponding file URI. Temporary on-disk resources depend on a cleanup hook, which may or may not run, depending on whether the language server process is forcefully terminated.
Similar to how the Java language server does this, it might be cleaner to have a custom URI scheme for resources inside JAR files. For example, replacing:
file:///C:/Users/.../AppData/Local/Temp/fernflowerOut8413035485521351592/Runnable7065471160245853737.java
by something like:
kls://contents/rt.jar/java.lang/Runnable
VSCode supports this through the use of Virtual Documents, Atom provides an API for readonly documents too.
Challenges with this approach include, however:
java/classFileContents
)For discussions around the JDT's approach, see:
jdt://...
not supported autozimu/LanguageClient-neovim#392The text was updated successfully, but these errors were encountered: