java-language-server: init at 0.2.38

[hqurve]

Motivation for this change

Something I would like, also its a packaging request closes #128999

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• 21.11 Release Notes (or backporting 21.05 Relase notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[hqurve]

Tested on linux using neovim with lspconfig

require'lspconfig'.java_language_server.setup {
    cmd = {"/nix/store/spnkfdwa630vfv3zqdwix0qa2zy5752x-java-language-server-0.2.38/share/java/java-language-server/lang_server_linux.sh"},
    on_attach=on_attach,
    root_dir= require'lspconfig/util'.path.dirname,
}

[r-rmcgibbo]

Result of nixpkgs-review pr 131262 at bfd1f4db run on x86_64-linux 1

1 package built successfully:

• java-language-server

1 suggestion:

• warning: missing-phase-hooks

  installPhase should probably contain runHook preInstall and runHook postInstall.

  Near pkgs/development/tools/java/java-language-server/default.nix:68:3:

     |
  68 |   installPhase = ''
     |   ^
  

[hqurve]

@houstdav000 @winston0410 Would you mind testing the derivation in your editor of choice? It works for me on neovim (with lspconfig) on nixos but I dont know if I may have missed something.

All you would have to do is copy the java-language-server/default.nix to some location in your configuration and then add environment.systemPackages = [(pkgs.callPackage ./path/to/file {})] to your configuration. You can of course add it to a shell.nix too but this is just an example.

By default, there is an executable called java-language-server (which in turn calls dist/lang_server_{platform}.sh) on your path.

Thanks

[winston0410]

@hqurve I am using the exact same config with you, and it is working correctly!👍👍

Btw I have asked the java reddit, and they seems to prefer jdtls over this language server. I will be grateful if you could package that as well.

[winston0410]

This is the related issue for jdtls, I am not good enough in nix to understand why it is stopped right now.

#97814

[hqurve]

@hqurve I am using the exact same config with you, and it is working correctly!+1+1

Great

Btw I have asked the java reddit, and they seems to prefer jdtls over this language server. I will be grateful if you could package that as well.

This is the related issue for jdtls, I am not good enough in nix to understand why it is stopped right now.
#97814

There are currently two PRs, #99330 and #107424, opened for this; although that its for an older version (I think the current one is 1.2.0). Regardless, I would look at it (even if its just for fun)

[raboof]

Result of nixpkgs-review pr 131262 run on x86_64-linux 1

1 package built:

• java-language-server

[raboof]

Generally looks good to me. 2 small comments. I wonder if we shouldn't put energy into packaging jdtls instead, if that is preferred over this, though :)

[raboof]

Is there a reason this needs to be a script and can't be a symlink?

[hqurve]

Yeah, I mentioned it in the comment in the code, but I guess I should expand. Suppose it was a symlink and consider this line in lang_server_linux.sh. According to my testing and this answer, $0 would refer to the symlink and not the target file. Therefore, dirname $0 would evalate to /nix/store/...java-language-server/bin instead of ...../java-language/server/share/java/java-language-server and as you can see this would cause issues in the rest of the code.

Initially, I tried to symlink it but when I noticed this, I only saw two solutions, have a script like how it is done in the AUR or patch the files. I wasn't sure how to properly patch the files in a simple manner, so I resorted to a script.

Please let me know if there is better way to solve this issue (perhaps using symlinks)

[raboof]

Doh, I should have read more closely :).

perhaps wrapProgram/makeWrapper might be slightly nicer, but that's a matter of taste.

[hqurve]

Thanks, I didnt know such a tool existed

[raboof]

This is slightly different from the example at https://nixos.org/manual/nixpkgs/unstable/#double-invocation - any reason to use $out/.m2 rather than just $out?

[hqurve]

Looking at it too, none that I could think of. (Perhaps its an artifact of when I was having issues trying to get it to build) Ill change it to just $out.

Also, the reason to skip the tests, the build instructions say to skip them and indeed, I was getting an error when I let them run. (Ill attempt to build it to show you the error)

[hqurve]

I ran the tests and I believe all of the errors were caused by a module not being exported

java.lang.IllegalAccessError: superclass access check failed: class org.javacs.ReusableCompiler$ReusableContext (in unnamed module @0xb6a0f7) cannot access class com.sun.tools.javac.
util.Context (in module jdk.compiler) because module jdk.compiler does not export com.sun.tools.javac.util to unnamed module @0xb6a0f7

I believe this problem could be mitigated by adding

<arg>--add-exports</arg>
<arg>jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED</arg>

to each of the dependency compilerArgs in pom.xml but ... ill wait to see what you say

[hqurve]

Yeah, I agree jdtls should have higher priority than this, but by the time when I realized, it was already too late.