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.
Related
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
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
I'm trying to package a small application (still learning Scala!) in a "clean way". The goal is to have an executable JAR file. I've done the following:
packaged a JAR using sbt -> will work with
scala -cp myjarfile.jar MyClass
or
java -classpath path\to\scala-library.jar;myjarfile.jar MyClass
but won't work with
java -jar myjarfile.jar
because then scala/ScalaObject cannot be found. And no use adding a classpath on this last one, since the -jar option will ignore the -classpath option. Note that I have added the scala libs in my system CLASSPATH variable, but it seems to be ignored too when -jar is used.
added the scala library contents (by unzipping them first) to the jar created by sbt. This then works (the jar can be double-clicked and launched), but the manipulation is somewhat lengthy, and the resulting file is several megabytes big. Not ideal.
After hours of googling, I can see no way to create a small jar file that will launch when double-clicked and that doesn't involve a painful manipulation. What am I missing? I'm guessing there should be some way to define where the scala libraries are at system level. How do you deal with small applications that you want to be compiled and ready-to-run for efficiency?
Note that while I'm using sbt, I don't have a jar tool at hand (I'm relying on a JRE, not a JDK).
Thanks!
Pierric.
The following setup works for me:
have scala-library.jar in the same folder as the executable jar (and call java from there)
put this into your manifest:
Class-Path: scala-library.jar
Another option is to merge the contents of scala-library.jar into your application jar. The drawback is that this will increase its size. But you can use Proguard to strip unused classes from your final jar. I think there is an easy way of using sbt to package an executable jar using proguard.
Regarding the shrinking using Proguard, you can have a look at this page. It's about Android development; just ignore this part and have a look at the tables of the shrinking results. Some example applications shrink to less than 100kB.
Edit
Maybe you need to refine your question a bit. What are you trying to achieve? Do you want to install the program only on your system or do you want to distribute it?
If all you want is quickly launching a Java application without much impact of the JVM start-up time you can have a look at nailgun.
I've got a relatively large Java application that would benefit from a bit of Python love. To that end I've been working on getting it up and running in Jython. My current roadblock is getting the classpath right.
I've taken two approaches to setting the classpath:
Using a shell script, I've built up a list of jars and executed java -cp ${CP} -jar jyton.jar where $CP is a list of the jars needed for my app. This doesn't seem to work. I'm unable to import any classes from these jars, getting only ImportError: No module named apache instead.
Using a bootstrap python script, i've created a list of paths using glob, and appended them to the current path using [sys.path.append(path) for path in JAR_LIST]. This seems to work correctly; I can now import any of the classes I need to from the included jars.
The above is a bit confusing as most information I've been able to find has steered towards using $CLASSPATH and -cp to added your jars, but I can't get that to work. So the question so far: Is #2 the proper way to add dependancies to your classpath when using Jython?
The main reason I question my methods is because I'm still having problems fully utilizing my application. A number of places in my app reverences resources using relative URLs : classpath:some-critical-file.xml
some-critical-file.xml and a number of my classes reside within the same jar. I'm able to import classes from that jar, but any attempts to load my xml with classpath:some-critical-file.xml results in a java.io.FileNotFoundException
Any insight as to why my classes are available but relative paths to resources using classpath: are not would be much appreciate. I'm at a loss at this point.
I've run into a little classpath weirdness myself lately. Have you tried the old school approach of:
CLASSPATH = ${CLASSPATH}:your.jar
export CLASSPATH
jython your_script.jy
If you're invoking the standalone jar using java -jar then from the Java Documentation ...
-jar
When you use this option, the JAR file is the source of all user classes, and other user class path settings are ignored.
So it it not possible to add anything to the classpath when using -jar. See this answer for a solution - basically add the jython.jar to the classpath (either using -cp or CLASSPATH) and run the org.python.util.jython class directly.
What is the simplest way to package a Scala application for use on a desktop PC? I'm guessing that would be in the form of a jar file.
At the moment I'm using SBT to compile and run programs
I'd be interested in solutions for machines that have Scala installed (and the library in their classpath), as well as those that only have Java.
The simplest (and the most consistent) way to package a Scala application, is packaging into a JAR (like you do with normal Java applications). As long as JAR consists of standard compiled Java classes, you may run "Scala" JAR, even if you don't have Scala runtime at the box (all you need is a Java Runtime and scala-lang.jar on the classpath). You may specify the main class (gateway to functionalities of your application) in the manifast
Main-Class: mypackage.MyClass
so that you'll be able to call it only passing a JAR name to java.exe.
java -jar myjar.jar
You may specify the main class in SBT project definition.
http://www.scala-sbt.org/sbt-native-packager/index.html
The plugin allows you to package in a variety of formats(zip, tar, deb, dmg, msi, etc) and in different archtypes.