Question 278552 in Visual Studio Code Question posted in
View the official documentation.

Visual Studio Code code completion for Java not working

Visual Studio Code is not giving me any code completion for Java (just the word completion):

enter image description here

I have the JDKs configured:

"java.configuration.runtimes": [
    {
        "name": "JavaSE-11",
        "path": "/usr/lib/jvm/jre-11-openjdk",
        "default": true
    },
    {
        "name": "JavaSE-17",
        "path": "/usr/lib/jvm/jre-17-openjdk",
    }   
]

I have the Extension Pack for Java installed and I don’t get any error or something.

Any other suggestions what might be the problem?

Help: About

Version: 1.83.1
Commit: f1b07bd25dfad64b0167beb15359ae573aecd2cc
Date: 2023-10-10T23:45:31.402Z
Electron: 25.8.4
ElectronBuildId: 24154031
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: 11.4.183.29-electron.0
OS: Linux x64 6.5.8-200.fc38.x86_64

Red Hat Java Extension is v1.24.0 (I also tried rolling back to v1.23.0)

EDIT

Now I do get some errors:

Caused by: java.lang.NullPointerException: Cannot invoke "org.eclipse.jdt.ls.core.internal.preferences.PreferenceManager.getPreferences()" because the return value of "org.eclipse.jdt.ls.core.internal.JavaLanguageServerPlugin.getPreferencesManager()" is null
    at org.eclipse.jdt.ls.core.internal.preferences.Preferences.setJavaCompletionFavoriteMembers(Preferences.java:1378)
    at org.eclipse.jdt.ls.core.internal.preferences.Preferences.createFrom(Preferences.java:1126)
    at org.eclipse.jdt.ls.core.internal.handlers.BaseInitHandler.handleInitializationOptions(BaseInitHandler.java:113)
    at org.eclipse.jdt.ls.core.internal.handlers.InitHandler.handleInitializationOptions(InitHandler.java:105)
    at org.eclipse.jdt.ls.core.internal.handlers.BaseInitHandler.initialize(BaseInitHandler.java:64)
    at org.eclipse.jdt.ls.core.internal.handlers.JDTLanguageServer.initialize(JDTLanguageServer.java:284)
    ... 16 more

This error keeps coming and coming. The anlysis of the Java project never ends. Strangely while the analysis runs, the code completion now works.

EDIT

I did update to Java 17 on my machine, now at least the error messages are gone, but I still get no code completion for Java.

Fedora 38
OpenJDK 17.0.8
Tags:

2

Answers


  1. Chosen as BEST ANSWER
    0

    Oh, this is so stupid. I forgot to set some properties in my maven configuration.

    I set the Java version in the compiler plugin using two properties:

    <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <configuration>
        <source>${maven.compiler.source}</source>
        <target>${maven.compiler.target}</target>
    </configuration>
</plugin>

    But I forgot to set both of these properties. Strange this is, I did not get any error message, that they are not set. But I did also not build the project on the console.

    After defining the properties, everything worked as it should.

    So, thanks for all your help! And sorry for wasting your time!


  2. 0

    From the description of the symptoms in the question post- namely that a stacktrace containing Caused by: java.lang.NullPointerException: Cannot invoke "org.eclipse.jdt.ls.core.internal.preferences.PreferenceManager.getPreferences()" because the return value of "org.eclipse.jdt.ls.core.internal.JavaLanguageServerPlugin.getPreferencesManager()" is null is getting spammed in the logs, I think this is a case of this issue: is it is expected to have 19 GB of 1.1 mb log files in worksapceStorage
    #3349    . I suggest that you give that issue ticket a thumbs up to show that you’re having it, subscribe to it to get notified about discussion and progress, and contribute any information about how to reproduce the issue if you don’t see that same info already given in the discussion. Please avoid making noisy comments there like ones just containing "+1" / "bump". If you could help the maintainers giving repro info, that would be greatly appreciated. Ex. see the info request here.

    The cause of the issue is under investigation. Provided logs show that the failure happens when the extension tries to get a reference to the bundle context for jdt.ls.core– after which it seems to get stuck in an initialize loop due to the startup error.

    I wonder if you could work around the issue by rolling back to a previous release of the extension until the bug gets fixed and the new release rolls out? The timing of this question lines up nicely with the release of version 1.24.0 of the extension, so I suspect it being a bug introduced in 1.24.0.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search