Scala 2.13 console is incompatible with sbt client

sbt 1.4.0 is going to ship with a native thin client that will allow for users to connect to a running sbt server process to avoid the sbt startup time without having to an sbt shell session open (https://github.com/sbt/sbt/pull/5620). As it currently stands, the console task does not work with scala 2.13 because of the hardcoded jline Terminal that is passed into scala.tools.nsc.interpreter.jline.Reader via ILoop.defaultIn. My instinct is that it won’t be possible to make the client work with 2.13.3. Off the top of my head, there are two approaches (and possibly some combination) that could work for 2.13.4 compatibility:

  1. Update the ILoop api so that applications could pass in a jline Terminal (this may not be ideal because then jline becomes a part of the public api of the scala compiler)
  2. Alter the creation of the jline Terminal that presently occurs here: https://github.com/scala/scala/blob/691f6eb732c96ac9f013aff5878c83f79c6ac507/src/repl-frontend/scala/tools/nsc/interpreter/jline/Reader.scala#L72. In sbt, there is relevant code for creating a jline Terminal that relays to the client at https://github.com/sbt/sbt/blob/b678d2115fdc1a404b3a5290a74e8db13d455855/internal/util-logging/src/main/scala/sbt/internal/util/JLine3.scala#L77. The ILoop api could possibly have a boolean toggle (or it could check for a system property) so that the scala Reader can optionally create a custom terminal that uses System.in and System.out for the input and output streams (which sbt sets during task evaluation to redirect output to the remote client) and otherwise use the default terminal builder if the flag isn’t set.

It would be somewhat disappointing if the sbt client does not work with the scala 2.13 console. In case it wasn’t clear, the console task still works from the sbt shell or in batch mode with 2.13.

1 Like

I opened a PR to make this work: https://github.com/scala/scala/pull/9128

4 Likes

For an issue or bug, just report it under github issues. No need to start a post here

1 Like

I think starting a discussion here was warranted by the broader issue of REPL extensibility or adaptability or composability. The title might sound like a narrow issue.

The PR was closed because a workaround was discovered. It’s a bit tricky and involves class loaders. I almost commented: “I can’t wait to debug that!” But I wasn’t sure that my joking tone sufficiently expressed my admiration for the solution.

It would be nice if REPL were agnostic about its back end; I don’t know if the front end needs to be very pluggable or Swiss-army-knife-like. I might suppose that the REPL’s mission is to exercise the compiler, and that other-party tools might prefer to leverage Ammonite.

3 Likes