Beans: a new LSP for the JVM

I was working on my day job at the time, being a full-time contributor for Gradle. I don’t even remember why, but I opened up a Gradle-based Java project in VSCode. The experience was… subpar to say the least. I had RedHat’s Java extension installed, which I think is still regarded as the go-to Java extension. But when you open up a project, especially one that uses Gradle, you can see the limitations of this extension immediately: no Kotlin, no Groovy, I think the importing was broken as well. You get what you were advertised, a Java language server, but in the JVM ecosystem this feels quite weak.

The JVM, and honestly other VMs like .NET or BEAM, are great in my opinion because they allows parallel languages to coexist, and use the VM as the common abstraction to interact with each other. Your Clojsure code, written in a lisp dialect can interact with somebody else’s very-business AbstractNumberAdditionExceptionFactory. And I think this is great; I believe the ability that Kotlin could become a very serious, major language pushed the Java specification group to do more, and I’m happy to see the features coming to Java (and the JVM).

But the point is, you can already enjoy these interoperability benefits… if you use IntelliJ IDEA. But sitting there, with a project open in VSCode, borderline nothing functioning made me realize that the JVM space is so locked into JetBrain’s products. Sure, there is Eclipse, NetBeans and others, but the idea is the same: they are fully vertical IDEs, not reusable language servers.

I think editor choice should be free. I enjoy IDEA to be honest, but I reach for VSCode a lot, and maybe I want to get my feet wet living in the terminal, and setup NeoVim or Helix and have some fun. Seeing so many languages coming natively with their language server, making it easy and enjoyable to write code from the editor of your choice is a huge power, and I think the JVM should enjoy the same benefits.

See that I’ve said JVM, not Java. This is quite important. Let’s upwrap what are the challenges with language servers.

The limits of the LSP

I think LSPs revolutionized how new langauges can build good developer experience (DX) for their users. However LSPs have one big, critical shortcoming when it comes to these one-vm-many-languages setups: cross language server communication.

Simply said, the LSP says nothing about how different servers should or could communicate between each other. I don’t know the reasons for this, but this feels strange in retrospect: languages can, and are mixed into each other. Take the example below: using SQL in Java code. Not an idea that’s from another planet. IDEA, that is not limited by this design choice, can integrate it’s SQL intelligence for just that string segment:

// In IDEA, if setup correctly, this string will become a 
// semantically meaningful, highlighted code.
String sql = """
  SELECT name
  FROM users
  WHERE id = ?
  """;

try (var statement = connection.prepareStatement(sql)) {
  statement.setLong(1, userId);
  return statement.executeQuery();
}

And the same problem exists between, e.g. Java and Kotlin. If you have two different languages, with two different language servers, communication between them are going to be a pain. I’m not declaring that it is impossible but rather improbable.

And I had a realization: instead of making a language server for each JVM language, we have to step up on the ladder, and make a language server that serves the JVM and its languages as a whole. Thing start to click: if all the separate languages are indexed and served from the same server, we could implement interoperability: Java could suddenly talk to Kotlin, Clojsure or Scala, or whatever Beans would support.

Of course this is huge. I’m handwaving here grandoise ideas, but traditionally this would take forever to build. But we are not living in a traditional world anymore.

Hello, agents

I think in the past, after realizing this, I wouldn’t even try to do anything. This is just too big. We are still talking about multiple, separate, complex languages, where building an analysis engine is quite an involved process. Sounds like xkcd #1425; maybe with a team and five years.

But we have agents now, and I’ve got concrete ideas and experience how to do this. I am not certain that agents make this project feasible, maybe the challenge is still too big. But if I don’t try, I will never know. This is something I feel very strongly aboutfor me developer experience is everything—think would be unique and an interesting addition to the JVM ecosystem.