making it even more stressful ;)

now it downloads a ~200MB file and validating md5 on it.

As Nadav found out, we don't have to call defineClass and register each visible
Java class within the js scope, this makes it much simpler to integrate with Java
from the cli.

Not provided by the musl headers, and also unneeded.

Until now, OSV's console defaulted to raw mode, to make the CLI
happy. The problem is that on Linux, applications expect to be
run in cooked mode, so if we ever run a simple application that
tries to read user input, it can be confused.

This patch makes OSV console default to cooked mode, and the
CLI switch to raw mode before reading an input line - and reset
to the default mode just before running the user's command.

Unfortunately, we had to resort to adding a JNI class "Stty",
since Java has no builtin support for the ioctls required for
changing the tty settings.

uses Java nio.* for downloading a file, writing it to /tmp

requires starting qemu with tap networking, first install libvirt
then launch the run script as root with the -n option.

Example:

$ sudo ./scripts/run.py -d -n

in osv you'll have to configure networking as follows:

$ ifconfig virtio-net0 192.168.122.100 netmask 255.255.255.0 up
$ route add default gw 192.168.122.1

SPECjvm2008, uses the Thread.getContextClassLoader() class loader
to load classes - instead of using the current class-loader as any
decent code does when using reflection.

To allow this ugly, but officially supported, usage, we need to
set the context class loader in RunJar.java.

eventually causing a suspicious segfault.

class-static variable, which is not only strange, it also means we
cannot concurrently run several programs in several threads.

Change it so run() returns the (32-bit) return value, and when execution
fails (e.g., file not found), it throws an IOException.

Note that unlike Unix where main()'s return value is limited to 8 bits,
here we decided to allow the full gamut (63-bit) of return values from
main(). main() may return -23 or 2323813 and this does not indicate
an error running it (only an exception indicates an error).

This patch also removes the arbitrary limit of 256 command line arguments
(not that anyone would need more...).

All Java tests need to implement the Test interface and be registered with
TestRunner in order to be available to the test cli command.

TCPEchoServerTest is no longer accessible from javascript, instead, TestRunner is
now the interface of JS for running tests.

note: this class is not yet used by the CLI and will be used in a following
patch

split cloudius.jar to cloudius.jar an cli.jar
the following patch will introduce proper code reusing between the two jars
basically, cli.jar will be dependant on cloudius.jar

we're about to split cloudius.jar into 2 jars:
1. cloudius.jar - holds various utils and interfacing jni
2. cli.jar - wrappers needed for the cli, commuication of js<->java

per Nadav suggestion.

from javascript.

it translate the arguments recieved from javascript, invokes the jni method
and return the exit code to javascript

expects to recieve a String[] array as an argument, invokes run_elf()
and communicates the return value by setting a static int of the invoking
class

other classes may need to read/write global javascript objects, the run
command which is going to be commited in the next patch deals with it

the test creates 2 threads, a client and a server,
server is echoing back message received from the client.

this test extends ScriptableObject, which means it can be accessible
in the scope of rhino.

cloudius.jar's main entry point embeds rhino and execute cli.js

instead of running rhino.jar -f <file>, we now embed rhino within our own class
and completely control the context of the script engine.

reuse Global() from org.mozilla.javascript.tools.shell to initialize
our Context, this is done so we'll have functions such as importPackage()
available to Javascript.

this patch still doesn't replace rhino shell.