This is needed to start the JVM with debugger interface.

Signed-off-by: Tomasz Grabiec <tgrabiec@cloudius-systems.com>

We use the RunJava Java class to run Java applications (both java.so
and the "java" CLI command use it). We used to have RunJava.class
uncompressed, in the /java directory, but this caused two problems:

1. Or noticed that having a directory (/java) on the classpath causes
   thousands of stat() calls when Java tries to look for all classes
   in this directory. With a jar, its contents are read only once.

2. The "java" CLI command (java.groovy) didn't work because apparently
   Groovy cannot deal with classes being in the top-level package.

   So this patch moves RunJava into the io.osv package, and put it into a jar
   /java/runjava.jar.

   Note that java.groovy is changed in a separate patch (because it's in
   a different sub-repository....)

Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>

Add "-version" option to RunJava, and therefore to java.so and the "java"
CLI command.

java -version now shows:

  java version "1.7.0_25"
  OpenJDK Runtime Environment (1.7.0_25-mockbuild_2013_07_27_13_36-b00)
  OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)

I can't explain why the version on the second line is different than what
"java -version" on Fedora 18 shows for the same libjvm.so:

  java version "1.7.0_25"
  OpenJDK Runtime Environment (fedora-2.3.10.4.fc18-x86_64)
  OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)

Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>

JavaVMOption has extraInfo member that's not initialized in mkoption().
It only used by few special case options that provide a function pointer
hook to the JVM so it's harmless but fix it anyway.

Spotted by Coverity.

Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Add Cloudius copyright statement to files in java/. All of these (one C++
java.cc and the rest Java source code) are our own code.

Pass the "-D" command line options that are used to configure JMX, for
example, to the JVM.

Added a new function, osv::reboot() (declared in <osv/power.hh>)
for rebooting the VM.

Also added a Java interface - com.cloudius.util.Power.reboot().

NOTE: Power.java and/or jni/power.cc also need to be copied into
the mgmt submodule.

In the existing code, each -classpath or -jar paramter replaced the
classpath. This is inconvenient (and unlike the Unix "java" program).
Better just add to the classpath.

For example, now we can run:

  java.so -cp /java/cli.jar -jar /java/web.jar app

  Which runs web.jar's main class, but adds both cli.jar and web.jar
  to the classpath.

This is a fix for the previous commit (717693) that had an implicit
dependency on Ant js.jar

Breaks the build

A straightfoward implementation for SSHD
Supports SCP, SFTP subsystem and a shell through the current JS cli

Broken by 92b6753b.

The test command of the CLI didn't work because Javascript cannot work
with a Java String[] array as if it is a JS array, I was surprised to see
92b6753b and I assumed it works but
apparently the test command got broken.

This patch properly returning a Scriptable object that Javascript
code understands, it acquires a thread specific Rhino Context that
is used to cast the test names to a JS array, and from there the JS
code picks it up.

Pass -X* (and of course also -XX*) options to the JVM.
The -Xmx option is the most useful example.

The JVM options end with the first "-jar" *or* classname, not *and*.
Fix the typo.

Our CLI changes the console's tty mode to raw when doing its line
editing, and back to the original (cooked) mode when running a command.
Obviously, when we're running on a telnet connection we shouldn't touch
the console's mode like the existing code did.

OSV doesn't (at least for now) have ptys, so we can't handle the
telnet connection exactly like we handled the console, and the kernel
can't implement a "cooked" line discipline for us like it implemented on
the console. But we can do a very similar thing in Java instead:

This patch adds a new Java class, "TTY", which has an input and output
stream and an "stty" interface. We have one implementation for the console
(using System.in, System.out and the console's Stty), and a different
implementation, TelnetTTY, for a telnet connection.

This patch does not currently implement a line discipline ("cooked mode")
for this TelnetTTY, so it will always stay in raw mode. This is fine for all
our current uses of the CLI, but if in the future we have commands that read
user input and expect cooked mode (echo, line editing), we'll need to
implement this line discipline.

This patch adds a simple telnet server to OSV, implemented in Java.
One can telnet to the VM's IP address (default port 23) and get a CLI
shell. Multiple concurrent telnet sessions are supported (and the shells
are independent, as expected).

To start the telnet server, simply run the com.cloudius.cli.util.TelnetCLI
class. For example, in the CLI to start a telnet server in the background
use:

	java com.cloudius.cli.util.TelnetCLI &

To start OSV with only a telnet server, try

	sudo scripts/run.py -c1 -nv -m2G -e "java.so -jar
		/java/cli.jar java  com.cloudius.cli.util.TelnetCLI"

(The "cli.jar" in the last example is only needed to set the IP address...)

In the future we can turn the telnet server on by default - but let's
add a password feature first :-) Right now, there's no password requested
when someone telnets in.

The CLI used to assume it was using System.in, System.out (which point
to the console). Now make these parameters. We need this so we can run the
CLI on a telnet connection, and it doesn't send output to the console or try
to read from it.

RhinoCLI relied on a bunch of global Java variables such as _cx and _args.
This was not only ugly, it also prevents us from running multiple instances
of the CLI on the same JVM - e.g., to support multiple telnet connections.

There isn't actually a need for these JVM-wide global variables. At most,
we need to global use variables in the Javascript interpreter (so each
instance of the interpreter would have its own copy).

This patch puts main's arguments in a new global-per-javascript-interpreter
variable "mainargs" instead of the global-for-entire-JVM _args. "_cx" isn't
needed at all: one of uses was to for Java to convert a String[] into the
equivalent Javascript alternative - but Java should just return String[]
and let Javascript worry about handling that (it seems to work just fine
without change). A second use was for returning an exit code, but a more
appropriate methods to do the same thing without global variables exist.

Print useful error messages, instead of cryptic exception traces,
in three cases of "java.so -jar something.jar":

 1. When something.jar doesn't exist
 2. When something.jar exists, but can't be read as a jar (zip) file
 3. When something.jar exists, but doesn't have a "Main-Class" field
    in its manifest.

Starting the CLI and using the run command by specifying it as a run.py argument
didn't work due to a cast problem (run expected NativeArray).

previousely this didn't work:

$ sudo ./scripts/run.py -n -e "java.so -jar /java/cli.jar run tools/netserver-osv -D -4 -f -N" -c2 -m1G

This single Java source file is a full-fledged HTTP 0.9 server.
I wanted to add it to expose the console lock bug (fixed in a separate
patch), and to verify that bind() works correctly (it does).

But additionally, this tiny HTTP server (about 6KB of compressed bytecode)
can be very useful for our CLI - it can be run in the background and let
you view files in the OSV system in your browser, even while another
program is running.

To run Shrew from the CLI, just run

	java com.cloudius.cli.util.Shrew

Which runs the HTTP server in the background (in a separate thread),
letting the user continue to use the CLI. If you add an argument "fg" to
this command, it runs the server in the current thread, never returning.

Currently, the HTTP server is written to browse OSV's root directory
hierarchy: accessing http://192.168.122.100:8080/ from the host shows
you the OSV guest's root directory, and you can decend into more
directories and download individual files.

Exposes tracepoints and counters

The recent change, to add the program name as argv[0] for C code's
main(), make sense for C code, but less for Java code, where main()
normally expects args[0] to be the first argument, not the program name.

So the change to RunJava.java was un-Java-like; It also broke the "java"
CLI command which didn't put "java" in argv[0] for the arguments to
RunJava.main(), so the "java" command no longer worked after the previous
patch.

Instead, we change java.cc (which compiles to java.so). This is what
calls RunJava.class, and it should remove the new argv[0] before calling its
main() - instead of expecting that RunJava.class to do this.

the convention in linux is that argv[0] holds the program executable.
I had an attempt to run netserver not from the CLI and it didn't work because
its argument parsing got broken.

Added the possibility to pass to cli.jar a command, which it runs instead
of taking commands interactively. Note that the initialization script is
run before the given command.

After this patch,

        scripts/run.py -e "java.so -jar /java/cli.jar"

Continues to run the interactive command line editor loop, as before.
But additionally, one can do:

        scripts/run.py -e "java.so -jar /java/cli.jar ls"

To run just the command "ls" and exit - exactly as if the user would type
this command on the command line and exit the VM.

The given command can be, of course, much longer. For example to run Jetty
after the CLI's normal initialization script, the following monster can
be used:

scripts/run.py -n -e "java.so -jar /java/cli.jar java -classpath /jetty/* org.eclipse.jetty.xml.XmlConfiguration /jetty/jetty.xml"

(Funny how a single command should say "java" 3 times and "jetty" 4 times :-))

java.cc would exit right after the main() method finished. But in Java,
this is not the correct behavior. Rather, even if main() returns, we
need to wait for all other threads to end (or more accurately, wait
for all threads not marked with setDaemon(true)).

Calling jvm->DestroyJavaVM() does this for us, and it's probably the
Right Thing(TM) to do anyway.

Before this patch, the Jetty benchmark exited immediately after
startup.  After this patch, its worker threads keep the whole VM running.

Java.so used to correctly support the "-jar" option, but did not fully
allow the other "mode" of running Java: specifying a class name which is
supposed to be searched in the class path. The biggest problem was that
it only know to find class files, but not a class inside a jar in the class
path - even if the classpath was correctly set.

Unfortunately, fixing this C code was impossible, as JNI's FindClass()
simply doesn't know to look in Jars.

So this patch overhauls java.so: Java.so now only runs a fixed class,
/java/RunJava.class. This class, in turn, is the one that parses the
command line arguments, sets the class path, finds the jar or class to
run, etc.. The code is now much easier to understand, and actually works
as expected :-) It also fixes the bug we had with SpecJVM2008's "compiler.*"
benchmarks, which forced us to tweak the class path manually.

The new code supports running a class from the classpath, and also the
"-classpath" option to set the class path. Like the "java" command line
tool in Linux, this one also recognizes wildcard classpaths. For example,
to run Jetty, whose code is in a dozen jars in /jetty, one can do:

        run.py -e "java.so -classpath /jetty/* org.eclipse.jetty.xml.XmlConfiguration jetty.xml"

the new test creates several thread, each is downloading a ~280MB file
concurrently. It aims to find concurrency bugs in the netport, dead locks,
etc... but (fortunately) it pass.

making it even more stressful ;)

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