Bazel Language Server : Depend on the Bazel Starlark source code

Description of the problem / feature request:

Hello!

A few of my friends and I are working on developing a language server for bazel, built in java, for our university capstone project. We would like to use the java implementation of the starlark parser provided in this repo at the following location:

src/main/java/net/starlark/java/**/*.java

Our project is built using bazel, however we are unable to import these source files because many of them are marked as private. My question is, how would we best go about depending on these source files? Is this possible?

Thanks in advance for any help 😃

Feature requests: what underlying problem are you trying to solve with this feature?

Being able to depend on and use the bazel implementation of starlark so we can develop a language server that is consistent with the Bazel build system.

What operating system are you running Bazel on?

Linux

What’s the output of bazel info release?

release 3.7.1

What’s the output of git remote get-url origin ; git rev-parse master ; git rev-parse HEAD ?

[e-mail]:bazelbuild/bazel.git 3c685b6d2d34cd24450c11a902f1abfc3716d093 3c685b6d2d34cd24450c11a902f1abfc3716d093

[alandonovan]

could we reach out to you both in the future with any starlark/bazel specific questions as they come up?

Of course. Good luck!

[josiahsrc]

When we started this project, we weren’t very familiar with the Bazel ecosystem, language server protocol, or the different implementations of Starlark. We thought it best to use java for the language server for a few reasons.

• Bazel itself was primarily written in java. It made sense to us that the language server would also be written in java.
• We weren’t aware of the various implementations of Starlark. We figured that the ideal Starlark parser to use for our Bazel language server would be the Starlark parser written in Java, specifically designed for Bazel.
• Golang wasn’t listed as a supported SDK for language server protocol. See the officially supported SDKs here. We weren’t aware that there was an Go LSP implementation, albeit with little community support, or that we even needed to use one.
• “My main concern is that you don’t depend on Java class interfaces, as we don’t guarantee API stability. (We may, eventually, for the net/starlark/java/… subtree, but we’re not there yet.)”. The Java Starlark implementation, according to @alandonovan , may be released to the public. So, if there prove to be any inefficiencies with our DLLs, we could easily switch out the implementation and directly call the Java Starlark implementation.

We’re not needlessly trying to use Java. We picked it because, to the best of our knowledge, it would integrate well with Bazel. Given that you both don’t like the idea of a Java language server, I could speak with my team about switching to Go. Again, we want to build this to be used by the community, so we’re open to switching our design to what would work best. Switching would, of course, slow us down quite a bit because we would have to translate all of our existing code and infrastructure to Go.