bug#61371: 30.0.50; Adding support for jdt:// file scheme in eglot

bug#61371: 30.0.50; Adding support for jdt:// file scheme in eglot

[Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Hi!

When using Eglot along with Java there are some hacks that needs to be
made to make things functional.  One of the more important things is to
add support for the jdt:// file scheme that is sent when you try to
go-to-definition on a system or third party lib.

For completeness sake - consider:

```
import java.util.Li|st;

public Foo {
  void foo() {
    List foo;
  }
}
```

Cursor is now where | is, and if you try to M-., you won't get far.
This is because jdtls uses a convoluted way to retrieve this information
on demand, see [0].  Now the client has to query the language server an
additional time to get the actual content, load it somewhere, _then_
goto-def.  I've created one such hack for my own config, but maybe this
is something that could be mainlined, even though eglot itself is trying
hard to be language agnostic?  I'm not sure the code needs to live in
eglot, it could live some place other file-handlers live, if such a
place exists.  Anyway, the code I use to fix this now looks like this:

```
(defclass eglot-java (eglot-lsp-server) ()
  :documentation "A custom class for Java")

(cl-defmethod eglot-execute-command
  ((_server eglot-java) (_cmd (eql java.apply.workspaceEdit)) arguments)
  "Eclipse JDT breaks spec and replies with edits as arguments."
  (mapc #'eglot--apply-workspace-edit arguments))

(cl-defmethod eglot-initialization-options ((server eglot-java))
  "Passes through required java initialization options"
  `( :settings ,eglot-java-config
     :workspaceFolders [,(eglot--path-to-uri (project-root (project-current)))]
     :extendedClientCapabilities (:classFileContentsSupport t)))

(defun jdt-file-name-handler (operation &rest args)
  "Support Eclipse jdtls `jdt://' uri scheme."
  (let* ((uri (car args))
         (cache-dir "/tmp/.eglot")
         (source-file
          (expand-file-name
           (file-name-concat
            cache-dir
            (save-match-data
              (when (string-match "jdt://contents/\\(.*?\\)/\\(.*\\)\.class\\?" uri)
                (format "%s.java" (replace-regexp-in-string "/" "." (match-string 2 uri) t t))))))))
    (unless (file-readable-p source-file)
      (let ((content (jsonrpc-request (eglot-current-server) :java/classFileContents (list :uri uri)))
            (metadata-file (format "%s.%s.metadata"
                                   (file-name-directory source-file)
                                   (file-name-base source-file))))
        (unless (file-directory-p cache-dir) (make-directory cache-dir t))
        (with-temp-file source-file (insert content))
        (with-temp-file metadata-file (insert uri))))
    source-file))

(add-to-list
 'eglot-server-programs
 `(java-mode . (eglot-java . ("jdtls"))))

(add-to-list
 'eglot-server-programs
 `(java-ts-mode . (eglot-java . ("jdtls"))))
```

As you can see, we need to query the server with
:java/classFileContents, and also register with the server to send it
with the :extendedClientCapabilities on initialization.

Is there a place this code could live? Maybe in the new java-ts-mode?

Theo

[0]: https://github.com/eclipse/eclipse.jdt.ls/issues/2322#issuecomment-1313953316

bug#61371: 30.0.50; Adding support for jdt:// file scheme in eglot

[Michael Albinus]

Theodor Thornhill via "Bug reports for GNU Emacs, the Swiss army knife
of text editors" <bug-gnu-emacs@gnu.org> writes:

> Hi!

Hi Theo,

> When using Eglot along with Java there are some hacks that needs to be
> made to make things functional.  One of the more important things is to
> add support for the jdt:// file scheme that is sent when you try to
> go-to-definition on a system or third party lib.
>
> As you can see, we need to query the server with
> :java/classFileContents, and also register with the server to send it
> with the :extendedClientCapabilities on initialization.
>
> Is there a place this code could live? Maybe in the new java-ts-mode?

There is the jarchive package on GNU ELPA. Could this be used, perhaps extended?

> Theo

Best regards, Michael.

bug#61371: 30.0.50; Adding support for jdt:// file scheme in eglot

[Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Michael Albinus <michael.albinus@gmx.de> writes:

> Theodor Thornhill via "Bug reports for GNU Emacs, the Swiss army knife
> of text editors" <bug-gnu-emacs@gnu.org> writes:
>
>> Hi!
>
> Hi Theo,
>
>> When using Eglot along with Java there are some hacks that needs to be
>> made to make things functional.  One of the more important things is to
>> add support for the jdt:// file scheme that is sent when you try to
>> go-to-definition on a system or third party lib.
>>
>> As you can see, we need to query the server with
>> :java/classFileContents, and also register with the server to send it
>> with the :extendedClientCapabilities on initialization.
>>
>> Is there a place this code could live? Maybe in the new java-ts-mode?
>
> There is the jarchive package on GNU ELPA. Could this be used, perhaps extended?
>
>> Theo
>
> Best regards, Michael.

Maybe! Don't know what it does, but I'll check it out - thanks!

Theo

bug#61371: 30.0.50; Adding support for jdt:// file scheme in eglot

[Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Theodor Thornhill <theo@thornhill.no> writes:

> Michael Albinus <michael.albinus@gmx.de> writes:
>
>> Theodor Thornhill via "Bug reports for GNU Emacs, the Swiss army knife
>> of text editors" <bug-gnu-emacs@gnu.org> writes:
>>
>>> Hi!
>>
>> Hi Theo,
>>
>>> When using Eglot along with Java there are some hacks that needs to be
>>> made to make things functional.  One of the more important things is to
>>> add support for the jdt:// file scheme that is sent when you try to
>>> go-to-definition on a system or third party lib.
>>>
>>> As you can see, we need to query the server with
>>> :java/classFileContents, and also register with the server to send it
>>> with the :extendedClientCapabilities on initialization.
>>>
>>> Is there a place this code could live? Maybe in the new java-ts-mode?
>>
>> There is the jarchive package on GNU ELPA. Could this be used, perhaps extended?
>>
>>> Theo
>>
>> Best regards, Michael.
>
> Maybe! Don't know what it does, but I'll check it out - thanks!
>
> Theo

JDT urls are outside the scope of jarchive. I would think of them less
as URLs and more as tokens to be decoded by the LSP server that provides
them. JDT urls are intended to be sent back to the LSP server using a
special extension method.

There is an issue open in the eglot-java repo to implement this but I
have been too busy to get around to it
https://github.com/yveszoundi/eglot-java/issues/6

Someone has responded there with some code similar to jarchive that will
parse the JDT urls and try to open them, but I wouldn't consider that a
permanent solution. JDT urls are not standardized and subject to change
by the JDT LSP maintainers.

-- 
Danny Freeman

bug#61371: 30.0.50; Adding support for jdt:// file scheme in eglot

[Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Danny Freeman <danny@dfreeman.email> writes:

> Theodor Thornhill <theo@thornhill.no> writes:
>
>> Michael Albinus <michael.albinus@gmx.de> writes:
>>
>>> Theodor Thornhill via "Bug reports for GNU Emacs, the Swiss army knife
>>> of text editors" <bug-gnu-emacs@gnu.org> writes:
>>>
>>>> Hi!
>>>
>>> Hi Theo,
>>>
>>>> When using Eglot along with Java there are some hacks that needs to be
>>>> made to make things functional.  One of the more important things is to
>>>> add support for the jdt:// file scheme that is sent when you try to
>>>> go-to-definition on a system or third party lib.
>>>>
>>>> As you can see, we need to query the server with
>>>> :java/classFileContents, and also register with the server to send it
>>>> with the :extendedClientCapabilities on initialization.
>>>>
>>>> Is there a place this code could live? Maybe in the new java-ts-mode?
>>>
>>> There is the jarchive package on GNU ELPA. Could this be used, perhaps extended?
>>>
>>>> Theo
>>>
>>> Best regards, Michael.
>>
>> Maybe! Don't know what it does, but I'll check it out - thanks!
>>
>> Theo
>
> JDT urls are outside the scope of jarchive. I would think of them less
> as URLs and more as tokens to be decoded by the LSP server that provides
> them. JDT urls are intended to be sent back to the LSP server using a
> special extension method.
>
> There is an issue open in the eglot-java repo to implement this but I
> have been too busy to get around to it
> https://github.com/yveszoundi/eglot-java/issues/6
>
> Someone has responded there with some code similar to jarchive that will
> parse the JDT urls and try to open them, but I wouldn't consider that a
> permanent solution. JDT urls are not standardized and subject to change
> by the JDT LSP maintainers.

I think this bug can be closed now, it was fixed in the eglot-java
package. See: https://github.com/yveszoundi/eglot-java/issues/6

Thank you,
-- 
Danny Freeman

bug#61371: 30.0.50; Adding support for jdt:// file scheme in eglot

[Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Danny Freeman <danny@dfreeman.email> writes:

> Danny Freeman <danny@dfreeman.email> writes:
>
>> Theodor Thornhill <theo@thornhill.no> writes:
>>
>>> Michael Albinus <michael.albinus@gmx.de> writes:
>>>
>>>> Theodor Thornhill via "Bug reports for GNU Emacs, the Swiss army knife
>>>> of text editors" <bug-gnu-emacs@gnu.org> writes:
>>>>
>>>>> Hi!
>>>>
>>>> Hi Theo,
>>>>
>>>>> When using Eglot along with Java there are some hacks that needs to be
>>>>> made to make things functional.  One of the more important things is to
>>>>> add support for the jdt:// file scheme that is sent when you try to
>>>>> go-to-definition on a system or third party lib.
>>>>>
>>>>> As you can see, we need to query the server with
>>>>> :java/classFileContents, and also register with the server to send it
>>>>> with the :extendedClientCapabilities on initialization.
>>>>>
>>>>> Is there a place this code could live? Maybe in the new java-ts-mode?
>>>>
>>>> There is the jarchive package on GNU ELPA. Could this be used, perhaps extended?
>>>>
>>>>> Theo
>>>>
>>>> Best regards, Michael.
>>>
>>> Maybe! Don't know what it does, but I'll check it out - thanks!
>>>
>>> Theo
>>
>> JDT urls are outside the scope of jarchive. I would think of them less
>> as URLs and more as tokens to be decoded by the LSP server that provides
>> them. JDT urls are intended to be sent back to the LSP server using a
>> special extension method.
>>
>> There is an issue open in the eglot-java repo to implement this but I
>> have been too busy to get around to it
>> https://github.com/yveszoundi/eglot-java/issues/6
>>
>> Someone has responded there with some code similar to jarchive that will
>> parse the JDT urls and try to open them, but I wouldn't consider that a
>> permanent solution. JDT urls are not standardized and subject to change
>> by the JDT LSP maintainers.
>
> I think this bug can be closed now, it was fixed in the eglot-java
> package. See: https://github.com/yveszoundi/eglot-java/issues/6
>
> Thank you,
> -- 
> Danny Freeman

I agree :-)

bug#61371: 30.0.50; Adding support for jdt:// file scheme in eglot

[Stefan Kangas]

Theodor Thornhill <theo@thornhill.no> writes:

>> I think this bug can be closed now, it was fixed in the eglot-java
>> package. See: https://github.com/yveszoundi/eglot-java/issues/6
>>
>> Thank you,
>> --
>> Danny Freeman
>
> I agree :-)

Thanks, closed.