Work around MacOSX-specific Java 7 issue

Did this developer really state in the previous commit message that
Starting with Java 7, Oracle was tasked with maintaining Java for
MacOSX?

This is only half the truth, of course. The non-graphic-specific support
code was donated by the IcedTea team who wrote the original BSD support
code for Java. They started to adapt it to MacOSX (which is itself an
uncollaborating fork of OpenBSD) to be able to run newer Java versions
on older MacOSX versions. Their graphics backend was based on X11 and
thanks to Apple's decision to avoid integrating X11 windows seamlessly
into the desktop (instead keeping them as second-class citizens in the
X11 application with poor clipboard/keyboard/whatever support) IcedTea's
graphics support code for MacOSX was discarded by Oracle.

The Apple-specific support code for AWT/Swing was written by Apple and
donated to Oracle. It is likely of little surprise to anybody interested
that the Apple developers (or even more likely, their managers) decided
to rewrite that support code from scratch because that allowed them to
leave even slightly outdated MacOSX versions behind so that Java 7 --
which originally ran just fine on MacOSX 10.5, later MacOSX 10.6 --
requires at least MacOSX 10.7 now.

In their creative endeavor of creating ever more vendor lock-in, the
Apple developers also managed to keep the control of what they call the
"JavaRuntimeSupport.framework". It is this framework that offers users
who dared to start a Java 6 application on MacOSX later than 10.6 to
download that tainted component that Apple would no longer ship with its
flawless operating system by default.

Unfortunately for the users, the JavaRuntimeSupport is not without
flaws. For example, even when a Java application is asking for a Java 7
runtime using the well-established dlopen() method that works so well
for all other operating systems, Apple's JavaRuntimeSupport pops up that
scary window offering to download and install Java 6. Only when jumping
through hoops (read: using Apple's CoreFoundation framework with its,
uhm, peculiar resource/string handling) does the JavaRuntimeSupport
comply with the wishes of the developers and users of Java 7 software.

What the Apple developers missed, however, is that there is a relatively
benign workaround: just dlopen() the libjli.dylib library (not even
using it at all) just before dlopen()ing the libjvm.dylib.

Let's hope that they never find out.

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

src/main/c/ImageJ.c

@@ -263,6 +263,24 @@ static int create_java_vm(JavaVM **vm, void **env, JavaVMInitArgs *args)
 
 	setenv_or_exit("JAVA_HOME", java_home, 1);
 
+#ifdef __APPLE__
+	/*
+	 * Thank you, Apple. Working around your excellent code quality has been
+	 * nothing if not entertaining.
+	 */
+	string_addf(buffer, "%s/%s", java_home, "lib/jli/libjli.dylib");
+	if (debug)
+		error("Work around attempt at MacOSX world domination: %s",
+				buffer->buffer);
+	handle = dlopen(buffer->buffer, RTLD_LAZY);
+	if (!handle) {
+		error("Could not open %s: %s", buffer->buffer, dlerror());
+		string_release(buffer);
+		return 1;
+	}
+	string_set_length(buffer, 0);
+#endif
+
 	string_addf(buffer, "%s/%s", java_home, get_library_path());
 
 	if (debug)