Added extension java.util.Collection#anElement

JavaRelease>>inDirectory refactored to not hard-code relative paths to java executable within JRE/JDK. Instead, let the individual release to convert java executable path to java home and other way around.

Workaround for JAVA NameSpace (from Java bridge) vs JAVA JavaPackage (from STX:LIBJAVA) A supe ugly hack for Java bridge: there's a name clash with JAVA namespace in Java bridge code. STX:LIBJAVA expects global JAVA to be a kind of JavaPackage to make code like JAVA java util ArrayList new working. However, if Java bridge is loaded before JVM is booted, then JAVA global is subclass of NameSpace (instead of JavaPackage) and thus the above code does not work. This commit workarounds this problem by checking whether existing JAVA global is a JavaPackage and if not, changes it's superclass JavaPackage. This is certainly a super-hacky solution, but the only other way is change either STX:LIBJAVA or Java bridge not to use JAVA namespace.

Bugfix in JavaVM>>initializeVM: do not deadlock caller if VM initialization failed.

Change JavaRelease to use output of `java -version` when validating Java installation directory.

Initial stubs for Java 8

Fix in JavaRelease::SunJDK122. Make #validateJavaHome2: to always return false, Java 1.2.2 is too old and not really supported.

Oops, fixed syntax error (missing dot)

Fixed JavaReleaser>>JDK6/JDK7

Made non-ASCII literals encoded using \uXXXX rather than using direct UTF8 in .java sources. On Windows javac by default asumes the file is in CP1252. Could be changed in config, but that makes config more fragile. See SO: http://stackoverflow.com/questions/464874/unmappable-character-for-encoding-warning-in-java