SBT puts compiled scala files in folder target/scala-<scalaVersion>.
As far as I understand class files contain JVM bytecode. They are language agnostic.
What is then the reason for the folder with the name of the language? I'd expect that class filed of both Scala and Java go to the same directory.
The compiled bytecode is language-agnostic, but of course, the code inside that bytecode may call out to libraries, including the Scala standard library. The compiler may also have generated calls into the Scala runtime.
The Scala runtime may change between versions, for example, the way lambdas are represented has changed completely in 2.12. A program compiled for Scala 2.12 will not work with a Scala 2.11 runtime.
So, while JVM bytecode is language agnostic, you still need the matching runtime.
Note that this is no different from any other language. If you compile C to native code, you still can't run your code, unless you have the proper C runtime in place.
SBT supports building the same project with multiple Scala versions (and then producing separate artifacts for them, etc.). These files will naturally be in the same path relative to their target directory (since this path is determined by the full class name). So different Scala versions need different target directories to avoid conflict.
Related
I have a library in a jar that I would like to use in a Scala.js project.
Is any jar usable as a dependency of a Scala.js project?
Or should the jar have been compiled in a specific way?
It depends on the library, and exactly how you're trying to use it -- there are some macro libraries that work, for example, and you can technically put anything in a jar -- but usually this doesn't make sense. Jars are usually composed mainly of JVM classes, which aren't compatible with Scala.js' JavaScript environment.
This is really the biggest practical difference between ScalaJVM and Scala.js -- while the language is identical, the libraries are entirely separate...
The jar must have been compiled by the Scala.js compiler, so that it contains the .sjsir files, necessary for compilation to JavaScript. If it was compiled by the regular Scala/JVM compiler, you will not be able to use it in a Scala.js project (unless it only contains macros).
See also How to add lib with jars to shared folder?
scala-2.11 folder appeared after recent update of IDEA and Scala plugin.
What should it be used for?
Usually such directories are used for binary version-dependent code. For example, macros in 2.10 are not source-compatible with macros in 2.11, so if you're building your project for different binary versions and you're using macros, it makes sense to put code which is only valid for the specific version in different source roots. SBT then will use the appropriate directory when compiling for 2.10 or 2.11.
If you're using SBT, though, you would need to set such thing up manually in the build definition. If you're not using SBT, then probably IDEA plugin was updated to handle such things by itself.
I am using scala in android. And I want to include some basic library to the project, and I found there are 2 jar one is scala-compiler and another is scala-library. What's the difference between them, and how should we choose one?
Scala-compiler - is a compiler itself, which (simply saying) takes .scala files and compiles them into the .class files. You don't need it to run already compiled .jar/.class file if you don't interpret scala-code in runtime (which usually you don't). Scala-compiler.jar is used by your built-tool/ide to compile your scala code. Sometimes third-party libraries may also want it as transitive dependency.
Scala-library - is a library that contains scala API (built-in functions, collections, concurrency etc.). Usually (99,9%) you need this.
Is there a simple way to follow the Scala convention and append the Scala binary version to the archive name and artifactID of Scala libraries in Gradle? Even better if it is possible to compile the library against multiple Scala versions.
The convention that you are referring to isn't built into the Scala plugin, but setting jar.archiveName should do the trick. Likewise, building multiple variants isn't currently a first-class feature, but can be achieved in various ways, for example by declaring a separate source set per variant, with each source set pointing to the same source and resource directories. A proof of concept that also handles variants in dependencies (similar to what's offered by sbt) was presented in my Polyglot Gradle talk at Gradle Exchange 2013.
Just starting to learn scala.. I can't seem to figure out how to compile something into a standalone application. I think I almost have a working .jar file, but keep getting a Main-Class error even though it's in the manifest,
Scala programs require at a minimum the scala-library.jar file that accompanied the Scala Development Kit whose compiler you used to compile the sources. This is in addition to any 3rd-party Java (or Scala) libraries you might use. So from the perspective of building a stand-alone application (i.e., one that can be launched with a java -jar ... command) you must treat the scala-library.jar like a 3rd-party library.