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.
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?
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.
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 have no Scala experience, but I need to create a JAR to include on a project's classpath from a single Scala source file.
I'm thinking there is a relatively straightforward way to do this, but I can't seem to figure it out.
The Scala file is here: http://pastebin.com/MYqjNkac
The JAR doesn't need to be executable, it just needs to be able to be referenced from another program.
The most convenient way is to use some build tool like Sbt or Maven. For maven there is the maven-scala-plugin plugin, and for Sbt here is a tutorial.
If you don't want to use any build tool, you may want to compile the code with scalac and then create the jar file manually by using zip on the resulting class files and renaming it to jar. But you have to preserve the directory structure. In your pastebin you use the package org.apache.spark.examples.pythonconverters, so make sure the directories match.
Btw, if you want to just integrate this piece of code with your java project, and using maven, you can have the scala code in your 1 project as well (in src/main/scala). Just use the maven-scala-plugin plugin and hook it to the compile phase, or some sooner phase if your Java code depends on it. However, I don't recommend mixing multiple languages in one project, I would split it into two separate ones.
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.