So I was looking at
bin/scalac and bin/scala, the Scala toolset equivalents of javac and java, and I found myself learning some stuff. For instance, scala (which executes a Scala, um, executable) is simply a shell script that sets a bunch of shell/environment variables and finally runs this command:
${JAVACMD:=java} ${JAVA_OPTS:=-Xmx256M -Xms16M} -Xbootclasspath/a:"$BOOT_CLASSPATH" -cp "$EXTENSION_CLASSPATH" -Dscala.home="$SCALA_HOME" -Denv.classpath="$CLASSPATH" -Denv.emacs="$EMACS" scala.tools.nsc.MainGenericRunner "$@"
This points out some interesting interestingness. First off is: Scala executables are ultimately run by...
java! Or what passes for it on your system. Pretty neat, huh? Although it makes total sense if you think of java as the command that starts up a JVM on some arbitrary .class file, not the command that runs a Java(TM) language program.(Author's Other Note: Scala code gets compiled to JVM-compliant bytecode. Which is proof that real closures are theoretically possible in Java(TM). Although they are not likely to happen in your lifetime. But I digress.)
Second off is: buried amongst the options to
java is the non-standard -Xbootclasspath/a:"$BOOT_CLASSPATH". Unlike plain ol' -Xbootclasspath, this option lets you append some arbitrary jars to the regular bootclasspath (hence the /a). In this case, what it appends is $SCALA_HOME/lib/scala-library.jar if it exists, which gives the executable access to the Scala standard library. Which includes among other things the package that implements Scala Actors. P.S.: It turns out there's also a
-Xbootclasspath/p, which stands for "prepend", but is not as funny when applied to Canadians.P.P.S.: I like the option to provide a default value for some environment variable that may not exist on a given system (e.g.,
${JAVACMD:=java}).P.P.P.S.: EMACS??? What the heck does that have to do with running a Scala executable? Time for some more research, eh?
