Edit:
Got it sorted, SCALA_HOME + /bin to PATH sets the default interpreter; i.e. typing "scala" from bash prompt invokes 2.9.1 in my case. Just downloaded 2.10.0.M1. Invoking /path/to/2.10/bin/scala from bash brings up 2.10 REPL.
I'll just add a terminal alias for 2.10 so I don't have to type out the path manually.
Original:
Do I need a guest VM to pull this off, or in Linux, can I somehow run 2.10 and 2.9 side-by-side?
Basically, I'd like to experiment with 2.10-M1 reflection and see what runtime havoc I can wreak on case classes while continuing with general 2.9.1 development.
If not, a Kotlin-esque web demo sure would be nice to mess around with during the 2.10 evolution...
There is no problem at all with installing multiple versions of Scala; just install them in two different directories. Make sure you call the right version of scalac, scala and other executables when you want to use a specific version.
Scala does not require any system-wide settings that prevent you from having more than one version on your computer at once.
They will co-exist just fine. Remember that scala is really just a thin wrapper around Java from a runtime perspective. That is:
you can run compiled scala using the standard $JAVA_HOME/bin/java as long as scala-library.jar is on the classpath
the REPL is contained within a scala distribution
Related
I have a scala project that I can run with sbt. Now I want to execute it as a stand alone app. How can I run it with the scala command and ensure the right version of everything, in particular the scala-library and JVM?
PS: Just to clarify what I mean by an example from ruby.
I write some ruby script which I use routinely. For example, to apply updates a bit more cleanly then the OS does.
When I wrote the script I used ruby 1.8.3. ( Making version numbers up here as an example. ) I used the command line ruby my_script.
Now the version is ruby 2.0.1. The script will not run under this ruby because of language changes. So I use the command line ruby1.8.3 my_script.
Or rather I embed it in the shebang line.
Simalarly I want to run a jar using scala my_jar.jar but it was a built using a scala version 2.8.3 and will not run with that command. How do I make scala use the right version?
Two things you can try here:
1) The sbt-native-packager will create an executable. For example, you can create an RPM or Debian package.
2) You can create an "uber jar" using (say) sbt-assembly and package all your dependencies into a fat jar. You can specify a main function to be executed when running the jar (using the JVM java -jar a-jar-to-execute.jar command).
Both of the above are very active and widely used SBT plugins.
After your create the jar everything is in byte-code and you don't need to worry about Scala versions at that point. It will run as long as the Java (jvm) versions are compatible.
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 just wonder how can I extend Scala console and "script" runner with my own classes so that I can actually use my code by means of using the actual Scala language to communicate to it? Where am I to put my jars so that they can be seamlessly accessed from every Scala instance without ad-hoc configuration?
If you just need to interact with your code you can add a -classpath to the commandline when starting the repl.
scala -classpath mycode.jar
If you need to do more than that, start browsing the repl source. You can download it from github at https://github.com/scala/scala
I use sbt to accomplish this. It can start the repl with project classes and dependencies on the classpath by using "console" action.
You can use the CLASSPATH variable directly, e.g.:
CLASSPATH="/Users/opyate/.ivy2/cache/com.mongodb.casbah/casbah-core_2.9.1/jars/casbah-core_2.9.1-2.1.5-1.jar:/Users/opyate/.ivy2/cache/com.mongodb.casbah/casbah-commons_2.9.1/jars/casbah-commons_2.9.1-2.1.5-1.jar" scala
Is it possible to run scala files with Java Virtual Machine? I am trying a lot but nothing works. Can someone give me some help with command line? Thanks a lot!
Well, it depends on whether you are generating a JAR or class files, etc, but it is pretty simple: you run it like any Java program, but including the Scala library as a dependency.
java -cp .:/path/to/scala-library.jar MyApp
Scala runs on the JVM. It does not have a separate virtual machine. But it does have its own libraries, so you will need to have Scala installed wherever you're running it.
If it's compiled you will have a .class file, so you just type in
scala -cp myClassPath myPackage.myFileName
as you would with Java. You don't need the -cp option if you've navigated to your classes folder.
It is possible to run Scala classes using the java command - you can probably Google how to do it, but you would need to sort out all the correct imports and there's no reason not to just use scala as above.
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.