/ e	Binding E to Java

ELib's invocation mechanism only takes message name and argument arity as significant. Mapping this to pre-existing java code is problematic, as java allows overloading on type. (Of course, there's no problem for new code written to overload only on arity.) One can now invoke such java methods by using a message name that includes the parameter types. For example, given

Object[] args = { new File("/foo.txt") };
Object maker = new EStaticWrapper(FileWriter.class);

Btw, EStaticWrapper wraps a class so that its public static methods and constructors are available to ELib. As seen by ELib, constructors are methods named "new", so the following

FileWriter fw = (FileWriter)E.call(maker, "new", args);

or in E

def fw := java.io.FileWriter new file:/foo.txt

should invoke the FileWriter(File) constructor. Unfortunately, there are other public one-arg constructors, so ELib doesn't know which to choose. With this checkin, the following works:

FileWriter fw = (FileWriter)E.call(maker, "new(File)", args);

or in E

fw := java.io.FileWriter call("new(File)", [ file:/foo.txt ])

A mangled message names is an interned string consisting of
1) regular message name
2) open paren
3) list of types, separated by ", " (comma, space)
4) close paren.

Each type is
a) if a scalar, the scalar type name. e.g., char -> "char".
b) if an array, the base type followed by "[]".
c) otherwise, the last segment of the fully qualified class name.
eg, java.io.File -> "File".

We use only the last segment of a fully qualified name because I) this feature is intended only as a convenience, II) it corresponds more closely to how java code is written (even if it corresponds less closely to what the java code means), III) and I have never seen two overloads of one method name distinguished only on the package of the named types. If anyone has a reason why we need to support that case, please let me know.