feat: have class URIs use their original source name

[fbricon]

Fixes redhat-developer/vscode-java#4297

Draft until I go over all failing tests

[fbricon]

@datho7561 could you test this PR on non-vscode clients pretty please? Hopefully it should work everywhere

[fbricon]

There's an issue when opening module-info.class, when it works without this PR

I need to investigate

[datho7561]

It doesn't seem to be working for me outside of VS Code, here's what I tried:

1. Make a Maven project with okhttp3 as a dependency
2. In one of the Java files, make an instanceof of OkHttpClient, then trigger go-to-definition on it
3. I get a .class file with Java code instead of the .kt file

I'll double check that it works for me in VS Code as well, though

[fbricon]

okhttp3 is a different problem I was looking at this morning. Eclipse fails to open the kotlin sources because the jar file doesn't contain any .java file. This is due to JDT's SourceMapper.computeAllRootPaths() calling isJavaLikeFileName. Java-like extensions are loaded by getJavaLikeExtensions via an extension point.

I tried registering kotlin via :

   <extension point="org.eclipse.core.contenttype.contentTypes">
    <file-association
        content-type="org.eclipse.jdt.core.javaSource"
        file-extensions="kt,scala"/>
    </extension>

And then it works! But with a big caveat: any .kt file found in a source folder is now compiled as a java file and then you get plenty of compilation errors.

Sooo. This is an issue that needs to be handled in a separate ticket.

For now presto-jdbc sources work

[datho7561]

For now presto-jdbc sources work

Okay, I'll check that and get back to you

[fbricon]

You can try

<dependency>
      <groupId>com.facebook.presto</groupId>
      <artifactId>presto-jdbc</artifactId>
      <version>0.296</version>
</dependency>
<dependency>
      <groupId>com.typesafe.akka</groupId>
      <artifactId>akka-actor_2.13</artifactId>
      <version>2.8.8</version>
</dependency>

[datho7561]

Okay, I get Kotlin sources now, but the file extension is still listed as .class (Maybe that's just how it works for this neovim setup though) so I have to change the language over to Kotlin manually.

update: yeah works fine in VS Code, so I'm guessing it's something to do with the client code in neovim.

update: specifically something in https://codeberg.org/mfussenegger/nvim-jdtls, since go-to-definition doesn't work without it

[fbricon]

That's weird. jdt.ls used to send the kotlin content before as well, the only difference is now the URI path ends with .kt instead of .class

[datho7561]

Here's the client code where the classfile loading is being handled I think: https://codeberg.org/mfussenegger/nvim-jdtls/src/commit/f73731b543f5971e0da9665eb1d7ceffe1fde71f/lua/jdtls.lua#L1214

Notably, it sets the filetype to Java. This might cause problems?

[fbricon]

@mfussenegger any idea why nvim-jdtls would still list the source content as .class instead of .kt?

@datho7561 we need eclipse-jdt/eclipse.jdt.core#4738 to be fixed in order to see .kt files from source jars not containing .java files.

[mfussenegger]

@mfussenegger any idea why nvim-jdtls would still list the source content as .class instead of .kt?

nvim-jdtls should show the jdt:// as returned by the server without any modification unless users customized the display.
Neovim has no general hook for URI pretty-printing.

But looks like I'll need to adapt the logic in nvim-jdtls that calls java.decompile or java/classFileContents, currently it assumes the response will be java code. Should the client parse the URI and determine the filetype based on a .kt|.class or is there a better option?

--

Other question: Can eclipse.jdt.ls then handle if the LSP client attaches to those kotlin sources (didOpen, etc.) loaded via java/classFileContents? I so far assumed that eclipse.jdt.ls can only handle java sources.

[fbricon]

@mfussenegger yes you'll need to parse the url path, the actual file extension will be sent back. If for some reason you receive .class, it should be treated as .java

"java/classFileContents" should just be used to display source content. You're not supposed to call jdt.ls didOpen on it.

[mfussenegger]

"java/classFileContents" should just be used to display source content. You're not supposed to call jdt.ls didOpen on it.

Is there an issue doing it? So far I never noticed any problem. And it is currently required due to how the neovim lsp client works. To use other textDocument/ related LSP functionality like fetching symbols or goto-definition the client must be attached to a buffer, and attaching to a buffer automatically sends a textDocument/didOpen notification - which seems in line with the spec?

[fbricon]

OK so I double checked in vscode-java, didOpen is not called when opening a .kt source via "java/classFileContents", but .java content does it, so I guess you don't need to change anything there.

[fbricon]

We need eclipse-jdt/eclipse.jdt.core#4769 to be merged upstream to be able to get kotlin sources from kotlin-only jars

[fbricon]

Upstream fix has been merged and is available for jt.ls to consume, tested with any class from

<dependency>
  <groupId>com.facebook.presto</groupId>
  <artifactId>presto-jdbc</artifactId>
  <version>0.296</version>
</dependency>
<dependency>
  <groupId>com.squareup.okhttp3</groupId>
  <artifactId>okhttp-jvm</artifactId>
  <version>5.3.2</version>
</dependency>
<dependency>
  <groupId>com.typesafe.akka</groupId>
  <artifactId>akka-actor_2.13</artifactId>
  <version>2.8.8</version>
</dependency>

@mfussenegger any chance you can test this PR?

[mfussenegger]

On a quick test it seems to work.
With https://codeberg.org/mfussenegger/nvim-jdtls/pulls/19 the filetype is also set correctly to kotlin.

Can eclipse.jdt.ls also provide sources for other JVM languages - like scalar or clojure or is it only kotlin for now?

[fbricon]

I've added groovy, kotlin and scala for now, just need to update the extension point in plugin.xml to add more languages. Do you know any lib written in clojure?

[fbricon]

I added clojure as well.