Updater (cmd-line): add the 'list-local-only' command

This command allows you to list the files that have been installed locally
(i.e. not coming from any configured update site). This comes in handy in case
you need to investigate someone else's local installation, e.g. to check for
extra plugins that could be included in a personal update site.
Updater (cmd-line): add closing parenthesis
Merge branch 'updater-typos' of https://github.com/imcf/imagej

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Merge branch 'updater-list-local-only' of https://github.com/imcf/imagej

This adds the 'list-local-only' subcommand to the command-line updater.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Fix (ij-legacy tests: make sure that a main class is found)

For some reason, Jenkins on Windows did not fail without this change.
That was just a matter of luck, though. We really need to make sure
that the name of the 'main' thread is re-instated so that AppUtils
find the correct main-class.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Add a simple Java agent to identify when ImageJ 1.x classes are loaded

When ImageJ 1.x' classes are loaded before the ij-legacy patching had
a chance, we have a problem. The biggest problem is that we only have
a chance to detect that situation when the ij-legacy patching takes
place, so there is no way to know which code path loaded the unpatched
ImageJ 1.x classes.

To help with that, this commit adds a Java agent that reports whenever
classes in the "ij" package (or any of its nested packages) is loaded.

We will refine this agent in subsequent commits.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
LegacyJavaAgent: show only the relevant part of the stack trace

We do not need to show any part that is concerned with (possibly
nested) class loading, just the part in the user code that wants
to refer to ImageJ 1.x classes. So we hide anything inside the
bootstrap class loader (actually, the ext class loader, but that is
an implementation detail) and anything inside the LegacyJavaAgent
class itself.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
LegacyJavaAgent: Add documentation to the premain() method

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
LegacyJavaAgent: Add code to write out a minimal .jar file

When debugging ij-legacy itself, we need a minimal .jar file that
does not hide the classes we try to debug.

The newly introduced main() method does exactly that, copying the
LegacyJavaAgent .class file into a new .jar file.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Add a Premain-Class: entry so that the ij-legacy agent can be started

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
LegacyJavaAgent: Offer an API to switch the agent off

When the legacy patching is done, we should not warn any longer.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
ij-legacy: shut up the LegacyJavaAgent just before patching

The legacy java agent is supposed to warn when ImageJ 1.x classes
were used before patching, but it should no longer warn when that
patching starts (or afterwards).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Add the preinit() method to DefaultLegacyService

This method is supposed to perform the ImageJ 1.x class patching
required for the LegacyService to work correctly.

Previously, we tried to patch the classes when the legacy service
is initialized, but that is too late if the ImageJ 1.x classes are
used before.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Use DefaultLegacyService's preinit() method to force IJ1 patching

We used to abuse the getInstance() method for that task, but that is
inappropriate: we do actually not want an instance here. We want the
legacy service to run the things necessary before loading ImageJ 1.x
classes so that the LegacyService can be initialized properly later,
if at all.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
CodeHacker: provide better help when patching failed

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
CodeHacker: do not hide warning on stderr

When code patching failed, we should have a proper exception, not a
warning issued on stderr and a linkage error.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
LegacyJavaAgent: optionally overwrite the minimal agent .jar

When the main method runs with --force, it will overwrite the
specified target file.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
LegacyJavaAgent: add a usage

When specifying -javaagent:/path/to/agent.jar=help, it will show a
description of the agent and the options offered by it.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
LegacyJavaAgent: add the 'init' option

In the mode triggered by the 'init' option, the agent will simply force
the code patching of the ImageJ 1.x classes no matter what. This is the
safest and easiest method to fix issues when the CodeHacker complains
that the ImageJ 1.x classes were loaded before they could be patched.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
CodeHacker: mention the agent option 'init'

This is by far the easiest (if not the cleanest) way to solve the
problems...

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