Fix annotation processing when running javac without -d <directory>

Samuel Inverso noticed, and Mark Hiner diagnosed, that compiling SciJava
plugins using javac without specifying an output directory will write the
annotation index into an incorrect location (instead of META-INF/json/ it
is written into the top-level directory).

This can be verified using a very simple example x1.java file:

-- snip --
import org.scijava.plugin.Plugin;
import org.scijava.plugin.SciJavaPlugin;

@Plugin(type = SciJavaPlugin.class)
public class x1 implements SciJavaPlugin { }
-- snap --

The reason is that javac's DefaultFileManager will strip out any
subdirectory in the path passed to the createResource() method unless
an output directory is specified.

Work around that by detecting the situation and creating the subdirectory
explicitly.

This fixes https://github.com/imagej/imagej-launcher/issues/22.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Let Eclipse clean up AnnotationProcessor's source code

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Adapt instances of AnnotationValue in the annotation processor

Kevin Mader reported that certain @interfaces were not handled gracefully
because the annotation processor would encounter AnnotationValue instances
and not know how to handle them.

This fixes https://github.com/scijava/scijava-common/issues/130.

Without these changes, the example provided below yielded the following
exception:

	error: java.io.IOException: Cannot handle object of type class com.sun.tools.javac.code.Attribute$Constant
		at org.scijava.annotations.AbstractIndexWriter.writeObject(AbstractIndexWriter.java:252)
		at org.scijava.annotations.AbstractIndexWriter.writeArray(AbstractIndexWriter.java:306)
		at org.scijava.annotations.AbstractIndexWriter.writeObject(AbstractIndexWriter.java:243)
		at org.scijava.annotations.AbstractIndexWriter.writeMap(AbstractIndexWriter.java:288)
		at org.scijava.annotations.AbstractIndexWriter.writeObject(AbstractIndexWriter.java:249)
		at org.scijava.annotations.AbstractIndexWriter.writeMap(AbstractIndexWriter.java:288)
		at org.scijava.annotations.AbstractIndexWriter.writeObject(AbstractIndexWriter.java:249)
		at org.scijava.annotations.AbstractIndexWriter.write(AbstractIndexWriter.java:99)
		at org.scijava.annotations.AnnotationProcessor.process(AnnotationProcessor.java:91)
		at com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:627)
		...

-- snip BlockIdentity.java --
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

import org.scijava.annotations.Indexable;

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Indexable
public @interface BlockIdentity {
    String blockName();
    String desc() default "";
    String[] inputNames();
    String[] outputNames();
}
-- snap --

-- snip Test.java --
@BlockIdentity(blockName = "GrowRegionsBlock",
            inputNames= {"labeled image", "mask image"},
            outputNames= {"filled labels", "filled neighborhood"})
public class Test {}
-- snap --

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Merge pull request #131 from scijava/annotation-value

Adapt instances of AnnotationValue in the annotation processor
Merge pull request #129 from 4Quant/master

Addressing issue (https://github.com/scijava/scijava-common/issues/128) ...
Fix OptionsTest's assumption that bar was not persisted previously

Once the test ran successfully, bar is distinctively different from 0...

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

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

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
PrefService: Provide an API for Iterables

The most generic way to provide a bunch of Strings to persist is by
passing an Iterable<String> for writing and handling an Iterable<String>
when reading.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Add a data structure keeping n unique last-recently-used items

This is similar to the LinkedHashMap structure, except that an
already-existing item can be easily put to the front of the list, or the
back.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Add a history class for the upcoming script interpreters

The newly-introduced History class maintains the history of most recently
executed statements and has functionality to persist and retrieve the list
from the preferences.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Add the UI-agnostic part of the script interpreters

The newly-introduced ScriptInterpreter class provides all the
functionality of a script interpreter sans the graphical user interface.
It can execute statements and persists a history of most recently
executed statements.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Let LastRecentlyUsed implement the full Collection contract

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Test LastRecentlyUsed#remove(Object)

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
ScriptInterpreter: remove irrelevant modifiers
DefaultScriptInterpreter: remove redundant javadoc
DefaultScriptInterpreter: add final keywords
ScriptInterpreter: add missing punctuation
ScriptInterpreter: remember the associated language

It simplifies things downstream to be able to query the associated
ScriptLanguage later, since it is known at construction time anyway.

This does *not* persist the most recently used interpreter language!
DefaultScriptInterpreter: add more final keywords