1

I was wondering why https://www.scala-lang.org/download/ says

Scala is unusual because it is usually installed for each of your Scala projects rather than being installed system-wide.

Why is it not the case for Java? Can this way work for Java projects?

Thanks.

Tim
  • 1
  • 141
  • 372
  • 590
  • 3
    That way you do not have stupid problems at execution because you are running with a different version of the one which it was compiled or other common _"it works on my machine"_ problems. At difference of other languages, a Scala project specifies all the dependencies with their corresponding versions including scala and the build tool itself _(so you can just pull any project and it will work, without you needing more than a JRE and the SBT script installed)_ also, usually, built artifacts include all their dependencies, including Scala itself, so they can be run on any machine with a JRE. – Luis Miguel Mejía Suárez Mar 14 '20 at 18:44

2 Answers2

2

One thing is that, when talking about Java we need to distinguish JRE and JDK.
The JRE has JVM, so it's only the runtime platform for Java bytecode, JDK has compiler and other development tools.

Scala instalation already comes with compiler, interpreter, etc.

Both can run their own compiled code, but Java needs additional jars on classpath to run Scala programs (nicely described here).

Another and probably the main reason behind having separate installation of Scala for each project is that Scala is not fully compatible between its versions, i.e. particular version of Scala needs specific version of libraries.
(where Java is backward compatible)

itwasntme
  • 1,442
  • 4
  • 21
  • 28
2

If you use SBT, on the basis of scalaVersion specified in project's build.sbt, it will treat Scala like other regular library dependencies and download them under 

.ivy2/cache/org.scala-lang/scala-compiler
.ivy2/cache/org.scala-lang/scala-library
.ivy2/cache/org.scala-lang/scala-reflect

similarly to regular library, say, cats

libraryDependencies += "org.typelevel" %% "cats-core" % "2.0.0"

which would end up under

.ivy2/cache/org.typelevel/cats-core_2.13

We can also have system-wide installation of Scala under, say /usr/local/bin, however SBT will not use that and will read from ~/.ivy2/

Mario Galic
  • 47,285
  • 6
  • 56
  • 98
  • Thanks. I just revisit your reply. Does SBT need scala interpreter (either noninteractively running Scala scripts or interactively as REPL) or JVM bytecod interpreter ? – Tim Mar 18 '20 at 23:13
  • @Tim sbt drives programmatically in-process scalac API for source code to bytecode compilation. It communicates to the compiler via [compiler interface](https://www.scala-sbt.org/1.x/docs/Compiler-Interface.html). On top of that, it [also](https://stackoverflow.com/a/60706327/5205022) performs incremental compilation via [Zinc](https://github.com/sbt/zinc), and compiles project according to defined project structure. – Mario Galic Mar 18 '20 at 23:32
  • Thanks. I was asking about interpreters for Scala language and for JVM bytecode (compiled from Scala language), similar to commands `scala` and `java`. I was wondering if sbt stores the interpreters' .jar files under `.ivy2`? – Tim Mar 18 '20 at 23:35
  • @Tim Yes, interpreter (REPL) API is called from `scala-compiler.jar` dependency. – Mario Galic Mar 18 '20 at 23:49
  • (1) Is JVM bytecode interpreter API (similar to `scala` / `java` command) also in some .jar file under `.ivy`? (2) If you want to invoke Scala REPL in a shell, does SBT install it, or do you download Scala binary release and run `bin/scala`? – Tim Mar 18 '20 at 23:51
  • @Tim JVM is installed system-wide, not under dependency cache. You can start REPL from sbt by executing `sbt console`. This will use `scala-compiler.jar` from the cache. It has the added benefit that REPL will start with all the dependencies specified in `build.sbt` available. Alternatively you could also start REPL from system-wide installation of scala. It is up to you. – Mario Galic Mar 19 '20 at 00:03