Suppress unhelpful compiler warning

Yes, the classes are deprecated, and yes, we need to exclude them from
the encapsulation test...

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Reformat LegacyEnvironment's source code

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Add some well-needed Javadoc for disableIJ1PluginDirs()

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Add more cautious commitClass(String) method

The commitClass() method is used to make sure that the class loader has
a definition of the given class, possibly after patching said class. If,
however, the class loader in question is the same as the ij1-patcher
lives in, and a Class<?> parameter is required for the commitClass()
method, the class is loaded already, and cannot be patched later
anymore.

Therefore, let's just add a method that takes the class *name*, but keep
the old method for convenience in case we want to commit a class that we
do *not* want to patch anyway.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Avoid loading the EssentialLegacyHooks class before patching it

The recent changes to make the LegacyEnvironment configurable involve
optional patches to the EssentialLegacyHooks class. However, if the
class loader to load the patched classes is the very same that hosts
ij1-patcher (i.e. if there is no separate LegacyClassLoader instance),
we really cannot load said class before patching it. So let's be extra
careful.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Allow disabling the execution of the initializer class

The initializer class is supposed to be loaded via the PluginClassLoader
first thing after the encapsulated ImageJ 1.x instance has initialized.
It is used at the moment to guarantee a nice startup of Fiji, by letting
the initializer set up a full ImageJ2 context and install the
Fiji-specific extensions.

However, in the near future, we will switch to letting ImageJ2 start
everything up, defaulting to the LegacyUI. So we need a way to disable
the initializer.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Refactor the code to deduce a class path from a ClassLoader

We will need to use exactly the same code for the upcoming feature to
reuse the current class loader also for the plugins.

To support this feature, we will have to let the EssentialLegacyHooks
deduce the class path from the current ClassLoader so that the ImageJ
1.x plugins can be discovered appropriately.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Allow disabling the PluginClassLoader

This adds the noPluginClassLoader() method to the LegacyEnvironment.
When a legacy environment is configured that way, the patched ImageJ 1.x
will not instantiate a separate class loader to load the plugin. Instead,
it will try to discover the plugins from the same class loader that was
used to load the ImageJ 1.x classes themselves.

As a consequence, it does not make sense to allow users to call
Help>Refresh Menus: there is no way to unload plugin classes, once they
are loaded into the same class loader.

This method was added to support starting up an ImageJ2 context with
a legacy UI that itself starts ImageJ 1.x. If done that way, ImageJ2
and ImageJ 1.x *must* share a class loader, therefore ImageJ 1.x cannot
easily maintain a separate class loader for its plugins (in theory,
we could hardcode which class path elements are part of "core" ImageJ2,
but that would be a quite fragile solution, in particular when one keeps
in mind that personal update sites guarantee certain levels of version
skew to happen).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Add a test for the new noPluginClassLoader() method

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