Fix compile warnings pointed out by LLVM's compiler

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Be more verbose in debug mode about dynamic library loading

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Allow compiling the ImageJ launcher on MacOSX w/o Java 6

Up until Java 6, Java on MacOSX was maintained (for some creative
definition of the word) by Apple, in the form of a framework. These
frameworks are similar to libraries in the same way as MacOSX .app
directories are similar to applications: slightly broader concepts,
just incompatible enough to offer a nice vendor lock-in.

Starting with Java 7, however, Oracle was tasked with maintaining
Java for MacOSX, like they (and before them, Sun Microsystems) did
with all normal operating systems. Java 7 is therefore not a MacOSX
framework anymore, therefore we have to use the same method of
calling Java as everywhere else: dlopen().

To maintain backwards-compatibility, we need yet another MacOSX
specific profile, which we call MacOSX-Lion (thank you, thank you,
I find it rather inventive a term myself).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
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>
Add the ext directories on MacOSX even if there is no 'ext' bundle variable

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