package javax.naming does not exist(compiler.err.doesnt.exist)

[m-lnrs]

Hi :-)

I'm receiving the following error when trying to import javax.naming.AuthenticationException:

package javax.naming does not exist(compiler.err.doesnt.exist)

My project works fine when I package it with maven, it even runs on tomcat so I think it may be a missing java module.

Thanks.

[georgewfraser]

java-language-server bundles a standalone copy of Java, so that it works the same no matter what version of Java you have installed on your system. To make the bundled Java as small as possible, we only bundle the modules (pieces of the JDK) that java-langauge-server itself uses.

Unfortunately, java-language-server relies on its own bundled JDK to determine what classes are available:

https://github.com/georgewfraser/java-language-server/blob/80821b01df088b5690e75b19a27e350122cc92b2/src/main/java/org/javacs/ScanClassPath.java#L118

This is why when you type "AuthenticationException", it fails to autocomplete.

And when we create the Java Compiler that provides all the code intelligence, we don't specify what JDK to use:

https://github.com/georgewfraser/java-language-server/blob/80821b01df088b5690e75b19a27e350122cc92b2/src/main/java/org/javacs/CompileBatch.java#L113

This is why you get a red squiggly and an error message "package javax.naming does not exist".

I think the correct way to fix this is to specify the system-installed JDK using the --system option for javac: https://docs.oracle.com/en/java/javase/13/docs/specs/man/javac.html

We already do something similar to find src.zip, which contains the source of all JDK files, which we use to parse the doc-comments for autocomplete and hover: https://github.com/georgewfraser/java-language-server/blob/80821b01df088b5690e75b19a27e350122cc92b2/src/main/java/org/javacs/Docs.java#L52

If you want to take a crack at refactoring the code to set --system {jdk} as the default compiler option, it would be much appreciated!

[m-lnrs]

Hello @georgewfraser ,

Adding the --system {jdk} when it's available works like a charm! Thanks for all the explanation :-D

No error shows up anymore, but the autocomplete is still uncapable on finding javax.naming package due it's looking for modules on its own JDK bundle.

I came up with an idea after taking a look inside Docs class: scan all files inside the src.zip when JAVA_HOME is available on ScanClassPath::jdkTopLevelClasses. This way I get the javax.naming package autocomplete working just fine, but I don't know if it's the proper way to solve this.

Even so, I think if we only add --system {jdk} on CompileBatch will worth it.

Thanks again.

[georgewfraser]

I think we can fix autocomplete by telling jdkTopLevelClasses() to call classPathTopLevelClasses(_) with JAVA_HOME when it's available.

[georgewfraser]

Hmm. There are a bunch of complications around this. This might break when the user has a version of Java < 13 on their system. It makes JAVA_HOME a requirement, rather than a nice-to-have for JDK docstrings.

It's only another 46 MB to include the entire JDK in the distribution. I'm thinking about it...

[m-lnrs]

It really crash when I try to run with Java 1.8, sorry for that :-(

Include the entire JDK may be the best approach, but will the autocomplete suggest classes that are not in the user's JDK version? For example: user is using JDK 1.7 with no java.util.stream.Stream (since 1.8), the autocomplete will still show java.util.stream package to the user since its looking on it's own standalone copy of Java 13 isn't it? Even so, if there is no other alternative, I think it’s better than not having the autocomplete for Java classes.

Is there a way to create a compiler inside the java server language to check for errors on user's files with its own user's machine Java version (when JAVA_HOME is available) in place of using the standalone JDK 13 compiler that cames with the language server?

[georgewfraser]

Yes, that is correct, it will give you v13 autocomplete regardless of what version you're on. This cuts both ways---there are things in v1.8 that are removed in v13.

[ryantm]

@georgewfraser Hi, my name is Ryan and I work at Replit. We're trying to integrate java-language-server into our templates because it has much better resource usage than Eclipse's jdk-language-server.

Unfortunately, when we run it on our Java Swing template, it has this issue where it cannot find javax imports.

The fix referenced here that was reverted seems pretty simple, but looks like it ultimately has compatibility issues. Would it be fine to use this fix, if we ensure our JAVA_HOME java is the same java used by this language server?

Could you recommend someone who we could engage to support fixing this issue?