java: print exception thrown from FindClass

env->FindClass() triggers class initialization which may throw
exceptions. Instead of printing misleading information that the class
was not found we should print the exception stack-trace.
java: extract abstraction of isolated application

We aim to support running multiple isolated Java applications in one
JVM. Some work has already been done to isolate system class
loaders. There is much more to it than that. Isolated applications
(aka Contexts) do not map 1-1 to class loaders. One context may have
many different class loaders.

This change extracts context-specific logic to separate classes as a
base for further additions.
java: introduce utilities for lazy initialization

I need static-initialization-like semantics in several places.
This abstraction makes it easier.
java: create standard java module structure in runjava module

There is a convention to organize java modules in the following way:

src/main/java - source root for production code
src/test/java - source root for test code
java: use maven to build runjava module

It will allow to use automatic dependency management.

It slows down the build a bit. Incremental build takes 3 seconds
longer than previously.

First build takes longer due to downloading of maven artifacts.
This is once per machine.
java: implement isolation of java.util.logging managers

The j.u.l framework allows only one log manager to exist. To isolate
logging configurations we need to install our own log manager which
delegates to context-local log managers.

See #172.

In order to have a fully isolated logging config system properties
need to also be isolated. This will come in the following patches.
java: move context creation logic from RunJava to ContextIsolator

ContextIsolator is a generic API for starting new applications inside
a single JVM. RunJava should be just a command-line starter which uses
that API.

I tried to change as little as possible during the code move so that
any changes to that logic are clearly visible. The changes which adapt
the code to a more generic API are in the next patches.
java: make runSync interrupt the context on which it waits

Interrupting a thread which is blocked waiting for an isolate to
complete which was started via runSync() should interrupt the isolate.
The waiter should return only after isolate terminated.

I think this is what users would expect to happen when interrupting a
foreground process.
java: apply coding style

Auto reformat performed from IntelliJ (alt+ctrl+L)
java: move -version handling to RunJava

It does not belong in the isolate API but to the
command line java starter.
java: make ContextIsolator throw exceptions when arguments are invalid

Currently the error is just printed on the console. Throwing exception
allows API user to react on this situation in the most appropriate
way. For example if new application is started using a web interface
printing on console is useless.
java: remove support for -Xclassloader

We don't use it and I can hardly think of a way this could be useful.
java: cleanups
java: use varargs for run() arguments

This makes API more friendly.
java: fix possible NPE in expandClassPath()

File.listFiles() may return null. Spotted by IntelliJ.
java: get rid of redundant SandBoxedProcess class
java: isolate system properties between contexts

The solution is using Java reflection API to replace Properties object
in System.prop with a version which delegates to per-context
properties.

This allows each application to see different values for the same
property. This works with properties set via both command line
parameter (-D) and programatically with System.setProperty().
java: do not pollute isolate classpath with isolator dependencies

We don't want cglib classes needed by io.osv.* classes to be
accessible from application classes. This could cause problems
if application would want to use its own version of cglib. In this
case the application provided cglib would be masked by the one
inside OSv.

To solve this problem we do not set the current class loader
as application class loader parent, but instead we link it with
a proxy which combines bootstrap class loader and the original
system class loader allowing only classes from io.osv.* package
to be loaded from the system class loader.

Class loader diagram:

 +-----------+
 | Bootstrap |<---------------+
 +-----------+                |
      ^                       |
      |                       |
      |                       |
 +----+------+  io.osv.*  +-----------+
 | System    |<-----------| Filtering |
 +-----------+            +-----------+
                              ^
                              |
                              |
            +-----------+     |
            | App 1     |-----+
            +-----------+     |
                              |
            +-----------+     |
            | App 2     |-----+
            +-----------+

This way the application may still use OSv java APIs, but does
not see classes from our dependencies and may load its own version
of these classes.
java: set context class loader of context's main thread.

This is an optimization which saves the isolate code from going
through OsvSystemClassLoader proxy.
java: implement getClasspath() method in system class loader

Tomcat tries to invoke that method on the class loader if it is not instance
of URLClassLoader.

Makes the messages like this go away:

 Jan 22, 2014 12:30:21 PM org.apache.catalina.loader.WebappLoader buildClassPath
 INFO: Unknown loader io.osv.OsvSystemClassLoader@fce56f8 class io.osv.OsvSystemClassLoader