Add path to libjvm.dylib for Java 7 on OS X

Now that OpenJDK 7 is available on OS X, we can support
creating such a JVM via JNI, by linking to libjvm.dylib.
WIP: Remove mysterious OS-X-specific code

Otherwise, set_default_library_path never gets called
on OS X, leaving us no chance to link against OpenJDK 7.
Make error message more accurate
Improve Apple Framework JVM dir checking

Previously, it only tested for NULL. But it didn't actually
check whether the directories in question exist (which at
least on OS X 10.9, and probably also 10.8, they do not).
Fail if java path search finds an Apple framework

One of the ways the launcher attempts to locate a JRE is to look for
where in the PATH the "java" command comes from, including tracing back
through symlinks. Unfortunately, on OS X, this often ends up in the
Java Framework's Commands folder rather than in a proper JRE structure.
Do not try to link to the JVM if JRE path is NULL

It makes no sense to set JAVA_HOME to the result of get_jre_home() if
that function returned null. In that case, we should instead simply fail
to create the Java VM.
Use create_java_vm code on OS X for non-Apple JVMs

Previously, the create_java_vm method excluded the bulk of the logic on
OS X, period, assuming that if we are running on OS X then we will find
and use an Apple JVM only.

However, on newer versions of OS X (particularly on OS X 10.9
Mavericks), all the Apple JVMs are removed by default, and the JavaVM
framework is no longer in place to support them. That is, in
/System/Library/Frameworks/JavaVM.Framework/Versions there is no longer
a '1.6' or '1.5' folder, and instead only 'A' with a 'Current' symlink
to 'A'. So all the logic in set_path_to_apple_JVM fails and the function
fails with a "Could not locate compatible Apple Java VM" error.

Since we now return an error code for this situation, we can test for
it, and then continue to the non-Apple-specific logic in that case,
rather than always trying to blindly link to an unspecified and
probably-missing Apple version of Java.
Respect JAVA_HOME on OS X

If the call to set_path_to_apple_JVM succeeds (i.e., returns 0), that
means we found an Apple JVM. But when JAVA_HOME is set, we do not *want*
that Apple Framework JVM to be used, but rather would prefer to use the
JVM indicated by JAVA_HOME.

So let's make set_path_to_apple_JVM return a failure code if JAVA_HOME
is set, so that we can proceed with the non-Apple-specific JVM logic.
Fall back to Apple Framework if no JAVA_HOME given

This change addresses the following situation:

* A newer OS X (without Versions/1.6 or Versions/1.5 present)
* With OpenJDK 7 as the default java executable
* Apple Java 6 also installed (i.e., Versions/A is present)
* And no JAVA_HOME set (via --java-home or otherwise)

In this situation, the behavior had been that Apple Java 6 would be
used, via an immediate call to JNI_CreateJavaVM without setting
JAVA_JVM_VERSION first and without any additional wrangling. But with
the recent change to create_java_vm ("Use create_java_vm code on OS X
for non-Apple JVMs"), the behavior changed so that OpenJDK 7 (i.e.,
the java executable on the PATH) would be used by default instead, and
linked via the platform-independent code that uses dlopen and dlsym
instead of Apple's JAVA_JVM_VERSION with Apple's JNI_CreateJavaVM.

This change restores the old behavior of using Apple Java 6 by default
in this situation. The reason is two-fold: first, it preserves backwards
compatibility, of course. But even more importantly, without this
change, there is actually *no way* of telling the launcher to use
Apple Java 6 at all (since setting JAVA_HOME to the Java 6 directory
actually does not work the way the case logic is currently structured).

Of course, it would be nice to support JAVA_HOME pointing to an Apple
version of Java, but right now, the code is not smart enough to figure
out whether the JRE pointed to by JAVA_HOME is an Apple one or an
OpenJDK one. So for the time being, using Apple's Java by default in
these sorts of cases is hopefully an acceptable workaround.
MacOSX: Use Retrotranslator really only for Java < 1.6

When we do not detect Java 1.6, we used to fall back to Java 1.5, but now
that Java 1.7 is available for the newest MacOSX versions, Java 1.5 might
not be there, and then we have to stop insisting on using Retrotranslator.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Ignore temporary files used by vi

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Happy New Year!

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Retire the precompiled/ support

It was in a time long past that we tried to solve the problem Maven
solves so much more beautifully: avoiding the need to build everything
from scratch, but rather get trusted builds from a repository of
artifacts.

It is high time that we stop supporting that backwards-compatibility
wart.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Start refactoring the source code

We start by factoring out the string, allocation and the common
functions (error, die).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Organize #includes

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Avoid global variables

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Move prefixcmp/suffixcmp into common.h

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Move mystrlcpy() into string-funcs

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Move the PATH_MAX definition into common.h

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Factor out file functions

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>