Providing dummy ScalaInstance instances when compiling only Java code

[vasilmkd]

Hello everyone 👋🏻

I asked a question in the #sbt channel of the Scala Discord, regarding compilation of Java only modules/subprojects. My question was answered there, for which I am very grateful.

I was then advised to open this discussion topic, so that we could link against this question and answer in the future.

I will now copy the original question's text verbatim, as well as the answer by @lefou , thank you!

Link to the question on Discord

https://discord.com/channels/632150470000902164/922600050989875282/1157016277580263474

Original text of the question on Discord

Hi 👋🏻

I have a technical question that's getting into the sbt and Zinc weeds.

As you know, the IntelliJ Scala Plugin uses the Zinc incremental compiler to offer incremental Scala compilation when pressing the Build button in the IDE. This functionality was very generously donated by the lovely people at VirtusLab, some years ago. We have been maintaining it since.

There is an edge case that has recently been uncovered by our users, and it has to do with using Zinc in projects that have one or more pure Java modules/subprojects. As in, modules/subprojects that do not have any Scala source files in them, only Java.

In sbt land, this would look something like the following subproject definition:

lazy val core = project.in(file("core"))
  .settings(
    autoScalaLibrary := false,
    crossPaths := false
  )

Sbt handles this case by implicitly creating a Scala instance for this subproject. From my personal experience, it seems that this scalaInstance is created using the default scalaVersion version, which seems to be the version of Scala 2.12.x which was used to compile the specific version of sbt that is being used to build the project. Can someone please confirm this?

Even though we only have Java source code in this subproject, this scalaInstance is still necessary to instantiate the Zinc machinery (IncrementalCompilerImpl). So, sbt seems to handle this edge case gracefully. Our Zinc implementation also "just works" with these kinds of sbt projects, because during the IDE import process, this implicit scalaInstance is reported in our IDE, so we have all of the necessary information to instantiate the compiler.

But, this is not the case for gradle projects (and possibly also Maven multi-module projects, but I haven't yet verified this).
In gradle, if a user wants to compile Scala code, they have to enable the scala plugin in their build.gradle, for a given module (equivalent to sbt subproject).

But, the difference being in gradle, in the modules that are Java only, it's very often the case that users don't have the scala gradle plugin enabled in that module (naturally, because there is no Scala source to be compiled, so it is not necessary in that specific module).

For these gradle modules, we do not get this implicit scalaInstance, that we need to instantiate Zinc with. We would like to provide this scalaInstance ourselves.

We are currently experimenting how to exactly provide this scalaInstance. We can approach this in two ways. One is providing a proper instance, which we will infer from a different module in the same project (or somehow resolve on the user's machine). Or alternatively, we can create an empty scala-compiler.jar, just enough to instantiate a ScalaInstance object and pass it to Zinc IncrementalCompilerImpl. It seems that, in a simple experiment, we have been able to get away with the latter choice.

My final question is then, does anyone know what exactly this scalaInstance needs to look like, whether it possibly needs to be any specific version, and whether we can get away with a dummy instance like the one I described above? Remember, in this context, we don't need to compile any Scala code, the module contains only Java sources. Thanks.

[vasilmkd]

I am also including @lefou's answer to my question, both as a link, and in its full text.

Link to the answer on Discord

https://discord.com/channels/632150470000902164/922600050989875282/1157030929055875142

Original text of the answer on Disord, by @lefou

Hi @vasilmkd , I can't speak for sbt, but as the maintainer of Mill, I can tell you we also create a dummy Scala instance to use Zinc for Java-only modules. Here is a link to the code that instantiates such an instance. We even don't specify any exact Scala version, but just "".
https://github.com/com-lihaoyi/mill/blob/a614c898e485f79de42b514fef3389d04dd96c19/scalalib/worker/src/mill/scalalib/worker/ZincWorkerImpl.scala#L77-L92

[vasilmkd]

Anyone else, please feel free to weigh in on this topic. Thanks in advance.

[bjornregnell]

If this is similar to VirtusLab/scala-cli#2430
then it is now fixed here VirtusLab/scala-cli#2431
which might be useful as inspiration...

[ekrich]

Anything that makes people able to use Java or come from Java and make the transition using Scala builds tools or even Java tools is super great.

[eed3si9n]

My final question is then, does anyone know what exactly this scalaInstance needs to look like, whether it possibly needs to be any specific version, and whether we can get away with a dummy instance like the one I described above? Remember, in this context, we don't need to compile any Scala code, the module contains only Java sources. Thanks.

The only tested scenario is using some default Scala version, which doesn't really have to be "the version of Scala 2.12.x which was used to compile the specific version of sbt" since in sbt you can change ThisBuild / scalaVersion setting. As far as I know, we're only interested in invoking Zinc to get incremental behavior and to generate Analysis file so other subproject can perform incremental compilation, so it's likely that some dummy JAR might even work, but since we don't test that, I can't really guarantee if it would keep working.

[bjornregnell]

I think it would be good for beginners if sbt console just worked, even if they have just one .java file in their dir. The default scala version, if none explicitly given, should be the latest official IMHO (currently 3.3.1)

[bjornregnell]

It turns out that it does "just work", but old scala...

$ cat Test.java 
public class Test{ public void hi(){ System.out.println("hi"); }}
$ sbt console
[warn] No sbt.version set in project/build.properties, base directory: /home/bjornr/tmp/empty
[info] welcome to sbt 1.9.4 (Eclipse Adoptium Java 17.0.8.1)
[info] set current project to empty (in build file:/home/bjornr/tmp/empty/)
[info] Starting scala interpreter...
Welcome to Scala 2.12.18 (OpenJDK 64-Bit Server VM, Java 17.0.8.1).
Type in expressions for evaluation. Or try :help.

scala> (new Test).hi()
hi

I think it would be nice if it was latest (3.3.1)

[bjornregnell]

This is actually a use case that we have, where students try out java interoperability.

[bjornregnell]

(And the scala repl is so much nicer to experiment with java code compared to jshell...)