Trying to use the plugin with java 11 on OSX.

openjdk 11.0.1 2018-10-16
OpenJDK Runtime Environment 18.9 (build 11.0.1+13)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.1+13, mixed mode)

It is a simple project generate via springr.

I get the following error

Cannot inline bytecode built with JVM target 1.8 into bytecode that is being built with JVM target 1.6. Please specify proper '-jvm-target' optionkotlin(INLINE_FROM_HIGHER_PLATFORM)

You can reproduce using this repo https://github.com/laibulle/spring-kotlin-sample. The code run via

gradle bootRun

Best regards

Android compiles all of it's layout files into a R.java file that is compiled into the resulting apk file. The way we resolve this on other projects (such as vim-javacomoplete2) is to include the .class files from the build folders into the classpath that it uses.

This doesn't seem to work here. I've not delved into why yet - I'm assuming that this language server doesn't allow for classes on the classpath but it also could just be that Android Kotlin toolchain streamlines this somehow and doesn't output the same thing.

Opening this as a placeholder until I figure it out :)

When working with a Gradle project previously created in Intellij IDEA, the global functions mapOf, listOf, emptyMap, and similar all display as unresolved references. I'm not sure if this is a project configuration issue caused by moving from Intellij to VSCode, or if it's a bug, as I don't have any other types of projects available to test with.

I use this in vscode and open an Android project. For the 'Go to Definition' option, it works for the symbols in kotlin source code. However, it does not work for the symbols in jars or java files. For example, when I want to go to the definition of the class 'Application', it shows ‘No definition found for “Application” ’. Does this language server support 'Go to Definition' Completely？

The extension shows error on somethings that mustn't be error like Although an error disappears when importing java.lang but it still shows another error of the string array but in the two cases the compiler understands that and that is the result In addition it isn't autocompleting key words and other things which is highlighted with errors

I think that switching to the Affero GPL is a giant step forward. Open source is very import and software piracy is quite commonly with the MIT. So the GPL and AGPL protect the open source system and have some powerful copyleft. AGPL is quite popular on project like owncloud/Nextcloud, proxmox, estudio, mastodon, mongodb, Snap!. I think it's very important to use the GNU Affero General Public License instead of the MIT. Just to be sure that this code will be open source forever and not behind some legacy code. :)

And yes it's possible to switch from MIT to AGPLv3. :)

Some useful sources: https://tldrlegal.com/license/gnu-affero-general-public-license-v3-(agpl-3.0) https://exygy.com/blog/which-license-should-i-use-mit-vs-apache-vs-gpl/

At some point, I'd like to investigate support for this LS in Eclipse IDE and/or Eclipse Che. To achieve that, it's usually much easier if the LS providers a distribution that can be embedded in an Eclipse plugin or a Docker image without all the burden of doing a build. So it would be helpful if the project ships such easy to consume distribution.

This change resolves #182 on my end.

WARNING: I cannot ascertain if this change would work correctly in all cases, especially as some functionality was removed. Feel free to point out any cases I might have missed.

One thing I noticed is that all of the project's compiled classes get added to the classpath after this change (which is kind of the point, as protobuf generated classes are also there). I have not observed any negative effects of this so far.

Hi Kotlin Language Server developers,

Many thanks for a great project. I have been trying to set it up against emacs, but I must be doing something very silly because I get errors with KLS that I do not see when I manually run gradle. Let me first explain my setup. I am using Debian testing on x64 and I installed kotlin using SDK Man [0]. I have tried two distinct setups though, sadly, with more or less the same outcome.

Setup using Java 11

I have read through the many posts detailing how it is not possible to use Java 11 to build KLS - e.g. [1, 2, 3] - but it was still unclear to me if this limitation also applied to building user projects or only to building KLS itself [4]. So I started first by installing openjdk-11 and using the binaries supplied on GitHub [5]. Though there is no out of the box support on emacs for KLS [6], thanks to the help of the emacs lsp community, I managed to get emacs to start KLS and report errors on my kotlin code.

The weird thing was that it all worked well at first, but as I started to add more dependencies and change the project files, I started to see errors in KLS that I do not see in gradle. In particular, I see:

 Server.kt    20  27 error    INTER… kotlin: Calls to static methods in Java interfaces are prohibited in JVM target 1.6. Recompile with '-jvm-target 1.8' (lsp-ui)
 Server.kt    27  33 error    INTER… kotlin: Calls to static methods in Java interfaces are prohibited in JVM target 1.6. Recompile with '-jvm-target 1.8' (lsp-ui)

However, my gradle file states:

tasks.withType<KotlinCompile> {
    kotlinOptions.jvmTarget = "1.8"
}

In addition, my kts (gradle Kotlin script files) are riddled with errors:

 build.gra…     1  29 error    UNRES… kotlin: Unresolved reference: gradle (lsp-ui)
 build.gra…     3   1 error    UNRES… kotlin: Unresolved reference: plugins (lsp-ui)
 build.gra…     4   5 error    UNRES… kotlin: Unresolved reference: application (lsp-ui)
 build.gra…     5   5 error    UNRES… kotlin: Unresolved reference: id (lsp-ui)
...

The first error stems from this line:

import org.jetbrains.kotlin.gradle.tasks.KotlinCompile

To the untrained eye, it seems like the gradle kotlin DSL files are just not being picked up correctly.

Setup using Java 8

I then decided to investigate two questions:

• check if there have been fixes in master that address my problem;
• check if Java 11 is also not supported in user projects.

For this I relied on openjdk-8, but sadly it is not (entirely) available on Debian testing. The missing packages were downloaded manually from their FTP server [7]:

openjdk-8-jdk_8u212-b03-2_deb9u1_amd64.deb
openjdk-8-jdk-headless_8u212-b03-2_deb9u1_amd64.deb

Once installed I selected the java version via alternatives:

update-alternatives --config java

And set it to Java 8. I confirmed that my binaries were running from Java 8, as well as my local build using gradle. I then git cloned KLS and built it as per my understanding of the instructions:

./gradlew server:build
./gradlew server:installDist

It all worked fine. I then installed the resulting binaries, restarted emacs and picked up the new KLS. However, I am getting exactly the same errors as I had before, as per section above.

Conclusions

So it seems to me my problems are actually not related to the java version, but to my project. The weird thing is that when I run gradle build (or via the gradle wrapper) it all works. So I'm trying to figure out what KLS is doing differently. Can you point out to mistakes I have done on my setup, or if nothing obvious can be spotted, on ways to get more debug information about what KLS is doing?

Thanks very much for all your help.

Marco

[0] https://kotlinlang.org/docs/tutorials/command-line.html [1] https://github.com/fwcd/KotlinLanguageServer/issues/125 [2] https://github.com/fwcd/KotlinLanguageServer/issues/108 [3] https://github.com/fwcd/KotlinLanguageServer/issues/114 [4] https://github.com/fwcd/KotlinLanguageServer/pull/124 [5] https://github.com/fwcd/KotlinLanguageServer/releases/tag/0.1.13 [6] https://github.com/emacs-lsp/lsp-mode/issues/900 [7] http://ftp.debian.org/debian/pool/main/o/openjdk-8/

Java sources that exist in the jar files downloaded by gradle can now be opened

They are placed in $TMP_DIR/<relative_path_in_jar>/<file>.java If java file not found, proceed with usual class file finding Uncommented section in goToDefinition.kt as it doesnt seem to be causing any issues as seen so far Sample used: org.eclipse.lsp4j-0.5.0.jar

I understand that this is still a very rough implementation which probably fails under edge cases. Naturally, #45 is resurfaced as a result if the java files dont exist, so this should probably not be merged until such time as we can sort that out. Unfortunately, as the files extracted are Java files, we're at the whim of the features of the Java vscode extension after that if we're wanting to go down the chain of imports :smile:

Fixes https://github.com/fwcd/kotlin-language-server/issues/192

Sets up a VSCode extension to allow Java code to see Kotlin code. The extension depends on both vscode-java and vscode-kotlin. It uses the JDT LS extension mechanism, through a custom JDT LS extension that provides kotlin project importers for maven and gradle.

This seems to work reasonably well for small projects at least. I don't know how well it performs on bigger projects, but I think the concept looks valid and we can always improve that later.

Some notes:

• The VSCode extension uses the javaExtensions contribution point to provide vscode-java with the JAR for the JDT LS extension. The JDT LS uses the jar to find the kotlin project importers. The importers have higher priority than the default ones provided by the JDT LS itself.
• The JDT LS extension was built with Maven and Java since it would have been much harder to do it with Gradle and Kotlin (due to lack of documentation and editor support).
• The importers actually extend MavenProjectImporter and GradleProjectImporter provided by the JDT LS. As such, pretty much all the importing logic is done by the JDT LS. Once the core java project is imported (by MavenProjectImporter or GradleProjectImporter) we add the compiled kotlin files to the project's classpath. This is how the java code is then able to see the kotlin code.
• At the moment, the kotlin language server does not generate any bytecode (at least as far as I could tell). This PR also introduces this, since it is required for the JDT LS extension to work. The bytecode generated by the kotlin language server is written to a folder called kls at the root of the workspace. I chose this because the JDT LS messes with the default maven and gradle output paths (and we should try to isolate the language servers as much as possible). The code generation is only triggered on file save for performance reasons.
• Some language features are not supported yet (e.g., go to definition from java to kotlin doesn't work as you would expect it to), but the projects should no longer complain about missing symbols when referencing kotlin classes, etc.

How to test this for now:

On the vscode-java-kotlin folder, run the build.sh script to build the JDT LS extension. Afterwards, run npm install to install the VSCode extension dependencies. Once this is done, you can either debug it (using F5 on VSCode), or package it and install it from a VSIX. Important: The JDT LS extension will only work with the latest kotlin language server code (i.e, the one in this PR), so you should install the language server locally and setup your vscode-kotlin to use that (through the kotlin.languageServer.pathconfiguration property)

This is very experimental (I cannot stress this enough). This is literally the first thing I wrote involving Eclipse PDE and the JDT LS API. With that said, I think the concept at least seems to work, so I'm guessing we can improve this more over time.

Feedback welcome :)

Hi,

I'm trying to use this extension with a simple, standalone Kotlin source file. The file looks like this:

fun main() {
    println("Hello, world!")
}

With this, I get an Unresolved reference: printlnkotlin(UNRESOLVED_REFERENCE).

I have found some past issues that look similar: https://github.com/fwcd/kotlin-language-server/issues/73 https://github.com/fwcd/kotlin-language-server/issues/58

But I'm still not sure what I should do to make this work. Is there some kind of setting I need to change in order to work with standalone files?

I also saw that one issue mentioned something akin to a default Gradle directory or something, but, somehow, I can't find that issue anymore. Anyway, assuming that I have a completely fresh setup that has never touched a Gradle project, can I somehow make this work?

I have an installation of Android Studio, if that makes any difference. I have added the kotlinc and Java included with my Android Studio installation to my path, which enables me to compile my example file from the command line.

I noticed that the language server is unable to see all errors. E.g. for the modified code below from App.kt in https://github.com/fwcd/kotlin-quick-start/ no error is reported:

package quick.start

shouldMarkThisAsError

class App {
    val greeting: String
        get() = "Hello world."
}

however running ./gradlew compileKotlin reports: e: [...]/kotlin-quick-start/src/main/kotlin/quick/start/App.kt: (3, 1): Expecting a top level declaration

Consider the following code:

The type annotations include a callable type which can have string arguments which fail - but then if the string contains either > or ) that ends the type annotation early, resulting in the closing string tag being mistakenly recognized as opening a string.

Note that, I expect that it is not just strings that are not considered here, but other primitives too. I am not familiar with Kotlin though to be fully certain on what is allowed in the language here though.

when I open a Kotlin project build with gradle,the "Kotlin:Indexing" information is always displayed,and never disappear

here some infos may help:

• Macbook pro (10.15.7)
• java version:11.0.4.1
• kotlin version: 1.7.20
• gradle:7.5

• Ignore path when comparing versions
• Pick the local Kotlin stdlib version based on the compiled version. This prevents potential issues in case there are multiple Kotlin versions used on the same machine.