With scala 2 it was possible to pass system properties in the command line using -D<propname>=<propvalue> like in the following example:
$scala -Dpath.to.folder=/opt/myfolder
Scala v3 does not accept -D in the command line anymore:
$ scala -Dpath.to.folder=/opt/myfolder
bad option '-Dpath.to.folder=/opt/myfolder' was ignored
Welcome to Scala 3.1.0 (11.0.9.1, Java OpenJDK 64-Bit Server VM).
One possible solution (workaround) is to pass the properties through the environment:
$ env SYS_PROPS="-Dpath.to.folder=/opt/myfolder" scala
Welcome to Scala 3.1.0 (11.0.9.1, Java OpenJDK 64-Bit Server VM).
Type in expressions for evaluation. Or try :help.
scala> println(System.getenv().get("SYS_PROPS"))
-Dpath.to.folder=/opt/myfolder
scala>
How is it possible to pass system properties in the command line of scala 3 executables?
scala --help does not provide any useful info. Actually in scala 3.1.0 scala --help and scalac --help print the same message in the stdout.
Related
nvm (Node Version Manager) enables quick selection of alternative Node version to work with. Does Scala have a similar way of quickly switching different versions in the current shell? For example, say I want to start REPL with 2.12.10, then executing something something like
scala use 2.12.10
would greet with
Welcome to Scala 2.12.10 (OpenJDK 64-Bit Server VM, Java 1.8.0_202).
Type in expressions for evaluation. Or try :help.
Note the question is not about SBT via scalaVersion, but using scala command directly from the command line.
Alternatively to scala-runners, there's also sdkman, which is a more general tool but also supports scala. For example, command:
sdk use scala 2.12.10
sets scala to 2.12.10 for current shell session.
dwijnand/scala-runners
An alternative implementation of the Scala distribution's runners:
scala, scalac, scaladoc, and scalap (no fsc). They are implemented as
thin shell scripts around Coursier's coursier launch to add some Scala
runners-specific (power) options.
provide a quick way of starting different versions
scala --scala-version 2.12.10
and even development versions from
https://scala-ci.typesafe.com/artifactory/scala-integration
https://scala-ci.typesafe.com/artifactory/scala-pr-validation-snapshots
for example
scala --scala-version 2.13.2-bin-81d1da3
or particular pull request
scala --scala-pr 8960
I run Windows 7.
I have java (a current enough version to run scala) and scala downloaded on my computer. I've set PATH so that when I type "scala" into the command prompt it sends me to the proper interface:
Welcome to Scala version 2.9.1.final (Java HotSpot(TM) 64-Bit Server VM, Java 1.7.0_51)
Type in expressions to have them evaluated.
Type :help for more information
However I can't execute the command "scala" or "scalac" on my test files.
scala> scala Hello
(console):8: error: object Hello is not a member of package scala
This makes me think I'm in the wrong directory. The file Hello.scala is saved in the home directory that I set PATH to.
However I get a different issue when I try to compile code.
scala> scalac Hello.scala
(console):1: error: ';' expected but '.' found.
I actually got my test file to work at one point... but I wasn't actually IN scala.
C:\scala-2.9.1.final\bin> scala Hello.scala
Hello world!
I'm not really sure how to proceed from here. If anyone has any ideas of what may be wrong I would greatly appreciate input.
It appears that you're trying to run & compile programs from within the Scala REPL (read-evaluate-print loop - a kind of Scala interpreter) and you cannot do that in the REPL. The REPL allows you to type in Scala statements and see them execute immediately. (If you're not sure how you entered the REPL, you probably just entered the command scala from the command line.) The REPL is useful for testing ideas, and for experimenting with Scala. For example:
C:\some\path> scala
Welcome to Scala version 2.11.8 (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_91).
Type in expressions for evaluation. Or try :help.
scala> println ("Hello!")
Hello!
scala> val x = 10
x: Int = 10
scala> val y = x * 5
y: Int = 50
scala> sys.exit
C:\some\path>
However, the REPL isn't what you would use to compile & run Scala programs - you need to do that from the command line (or from a tool such as sbt). If you want to run your program directly from the command line, without using the REPL (that is, without being in Scala, as you put it) then you would need to do the following:
Firstly, compile your program using scalac:
C:\some\path> scalac Hello.scala
If that succeeds, you can then run the program with the scala command (which looks for a Hello.class file):
C:\some\path> scala Hello
(Here C:\some\path is the location of the files Hello.scala & Hello.class.)
Alternatively, as you have already discovered, you can run your Scala program as a script in the REPL. You can do this from the command line as follows (note the addition of the filetype .scala after Hello compared to the command above):
C:\some\path> scala Hello.scala
or from within the REPL:
scala> :load Hello.scala
Hope this helps!
You don't have to issue scala command when you're inside REPL. If you want to execute code from that file, load it:
here is what I have in Foo.scala
println("I'm foo")
Now I'm starting the REPL (and as you can see scala> is a sign that you're ALREADY into REPL and can start execute raw scala code):
Welcome to Scala version 2.10.3 (Java HotSpot(TM) 64-Bit Server VM, Java 1.7.0_25).
Type in expressions to have them evaluated.
Type :help for more information.
scala> :load Foo.scala
Loading Foo.scala...
I'm foo
How to find out, which version of JDK SBT uses?
My laptop has both JDK 1.6 and JDK 1.7 installed, so I was just wondering.
You can use eval at the sbt prompt with the appropriate system properties:
> eval System.getProperty("java.version")
[info] ans: String = 1.7.0_45
> eval System.getProperty("java.home")
[info] ans: String = /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre
(The other answers are fine too, this is just another method.)
Just run sbt console and you'll get something like this:
Welcome to Scala version 2.10.2 (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_45).
Type in expressions to have them evaluated.
Type :help for more information.
Which shows you the version of Java being used.
Cheers
JC
It's actually easy.
Find the command line of SBT (cat `which sbt`) and see which Java it is.
For example, my SBT command line begins with:
/usr/bin/java -Xmx512M
And /usr/bin/java -version tells the Java version, in my case it is 1.7.
sbt -v is another way:
# sbt -v
[process_args] java_version = '1.7.0_121'
# Executing command line:
java
-Xms1024m
-Xmx1024m
-XX:ReservedCodeCacheSize=128m
-XX:MaxPermSize=256m
-jar
/usr/share/sbt-launcher-packaging/bin/sbt-launch.jar
[info] Loading project definition from /root/.sbt/0.13/staging/a6d8e5030b69785a9763/build/project
[info] Set current project to xx (in build file:/build/)
>
Here's a batch file method I created to get that info immediately from the command line (Windows only, but you can do something similar in a shell script):
#echo off
setlocal
sbt "eval System.getProperty(\"java.version\")" "eval System.getProperty(\"java.home\")"
#echo on
Scala is installed and working fine.
scalacheck.jar is placed in the /bin .
I used the following command
$ scala -cp scalacheck.jar
After that, when i tried the below command,
scala> import org.scalacheck.Prop.forAll
I got the following error.
<console>:7: error: object scalacheck is not a member of package org
import org.scalacheck.Properties
^
I might have done some mistake in using scalacheck, please correct me and give the proper commands so that I can able to work with scalacheck in Ubuntu in interpreter mode.
Putting executable on the path isn't the same as jar being on the classpath, so your jar being in /bin didn't change anything.
Just use:
scala -cp path_to_your.jar
and you should be fine.
If for example, your scalachek.jar is in /bin then use:
scala -cp /bin/scalacheck.jar
edit:
Putting jars in /bin probably isn't the best idea.
You can use it like this:
kjozsa#walrus:~$ scala -version
Scala code runner version 2.9.2 -- Copyright 2002-2011, LAMP/EPFL
kjozsa#walrus:~$ locate scalacheck.jar
/usr/share/scala/lib/scalacheck.jar
kjozsa#walrus:~$ scala -cp /usr/share/scala/lib/scalacheck.jar
Welcome to Scala version 2.9.2 (OpenJDK 64-Bit Server VM, Java 1.7.0_03-icedtea).
Type in expressions to have them evaluated.
Type :help for more information.
scala> import org.scalacheck.Prop.forAll
import org.scalacheck.Prop.forAll
scala>
I'm getting compile errors when running the compile task as the sources reference new classes in java.nio.file package that only appeared in Java 7.
I have the following in build.sbt:
javaHome := Some(file("/opt/jdk/jdk1.7.0"))
fork := true
In sbt:
> show java-home
[info] Some(/opt/jdk/jdk1.7.0)
It compiles and runs fine in Eclipse. How can I set up sbt to use Java 7 for compilation?
The most reliable (perhaps only) way to do this at the moment it to start SBT with java in the JDK7 folder.
Modify your sbt launcher script; or use this one that allows you to specify Java Home (and so much more!) as command line options.
~/code/scratch/20111009 sbt -java-home /Library/Java/JavaVirtualMachines/openjdk-1.7-x86_64/Contents/Home
Starting sbt: invoke with -help for other options
[info] Loading global plugins from /Users/jason/.sbt/plugins
[info] Set current project to default-3e990a (in build file:/Users/jason/code/scratch/20111009/)
> console
[info] Compiling 1 Scala source to /Users/jason/code/scratch/20111009/target/scala-2.9.1/classes...
[info] Starting scala interpreter...
[info]
Welcome to Scala version 2.9.1.final (OpenJDK 64-Bit Server VM, Java 1.7.0-internal).
Type in expressions to have them evaluated.
Type :help for more information.
scala> java.util.Objects.equals(null, null)
res0: Boolean = true
Simply setting javaHome := Some(file("/Library/Java/JavaVirtualMachines/openjdk-1.7-x86_64/Contents/Home")) changes the Java version used to compile and fork processes, but does not change the version of the Java standard library on the classpath, nor the version used to run tests, which are always run the the same JVM as SBT.
If you use Linux or Mac, another possibility is to look at jenv, a command line Java manager.
It allows you to choose per project which JDK to use.
I use virtualenv, which is a tool from the Python ecosystem. In a nutshell, it is a shell script which allows you to change your PATH variable easily and get back to what it was before, if you need to.
First install virtualenvwrapper (a wrapper around virtualenv):
$ apt-get install virtualenvwrapper
Now create a virtual environment for, say, Java8 with Scala-2.11.
$ mkvirtualenv j8s11
Now, adjust ~/.virtualenvs/j8s11/bin/postactivate so that you define locations for all your tools. You can see an example below which works for me:
#!/bin/bash
JAVA_VERSION=1.8.0_31
SCALA_VERSION=2.11.5
SBT_VERSION=0.13.7
ANT_VERSION=1.9.4
M2_VERSION=3.2.5
GRADLE_VERSION=1.6
PLAY_VERSION=2.3.7
ACTIVATOR_VERSION=1.2.12
IDEA_VERSION=IC-135.475
PYCHARM_VERSION=community-3.4.1
TOOLS_HOME=/opt/developer
export JAVA_HOME=${TOOLS_HOME}/jdk${JAVA_VERSION}
export SCALA_HOME=${TOOLS_HOME}/scala-${SCALA_VERSION}
export SBT_HOME=${TOOLS_HOME}/sbt-${SBT_VERSION}
export ANT_HOME=${TOOLS_HOME}/apache-ant-${ANT_VERSION}
export M2_HOME=${TOOLS_HOME}/apache-maven-${M2_VERSION}
export GRADLE_HOME=${TOOLS_HOME}/gradle-${GRADLE_VERSION}
export PLAY_HOME=${TOOLS_HOME}/play-${PLAY_VERSION}
export ACTIVATOR_HOME=${TOOLS_HOME}/activator-${ACTIVATOR_VERSION}
export IDEA_HOME=${TOOLS_HOME}/idea-${IDEA_VERSION}
export PYCHARM_HOME=${TOOLS_HOME}/pycharm-${PYCHARM_VERSION}
PATH=${PYCHARM_HOME}/bin:$PATH
PATH=${IDEA_HOME}/bin:$PATH
PATH=${ACTIVATOR_HOME}:$PATH
PATH=${PLAY_HOME}:$PATH
PATH=${GRADLE_HOME}/bin:$PATH
PATH=${M2_HOME}/bin:$PATH
PATH=${ANT_HOME}/bin:$PATH
PATH=${SBT_HOME}/bin:$PATH
PATH=${SCALA_HOME}/bin:$PATH
PATH=${JAVA_HOME}/bin:$PATH
export PATH
Now you can just use workon to switch between environments. Example:
rgomes#terra:~$ workon j8s11
(j8s11)rgomes#terra:~$ java -version
java version "1.8.0_31"
Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)
(j8s11)rgomes#terra:~$ scala -version
Scala code runner version 2.11.5 -- Copyright 2002-2013, LAMP/EPFL
(j8s11)rgomes#terra:~$ workon j7s10
(j7s10)rgomes#terra:~$ java -version
java version "1.7.0_71"
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)
(j7s10)rgomes#terra:~$ scala -version
Scala code runner version 2.10.4 -- Copyright 2002-2013, LAMP/EPFL
I'm assuming you want to change whatever you have set in JAVA_HOME by default, which you can do when invoking sbt:
JAVA_HOME=<path-to-jdk-home> sbt
This works for me on OSX with sbt 0.13.8
change javacOption to 1.7? I don't think setting the javaHome is necessary.