From efaea16049ded0adba625238bf9c769798c4a18a Mon Sep 17 00:00:00 2001 From: Johannes Schindelin Date: Thu, 13 Feb 2014 16:31:11 -0600 Subject: [PATCH] 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 --- src/main/c/ImageJ.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/src/main/c/ImageJ.c b/src/main/c/ImageJ.c index 8642a479..1fc4e0b4 100644 --- a/src/main/c/ImageJ.c +++ b/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)