The basis of the new doclet are interfaces; primarily, jdk.javadoc.Doclet.
It is laborious for a casual implementer of this interface to provide all the
interface methods, providing an AbstractDoclet would help such a user
by removing the need to implement all the boiler plate required.

Joe's comments:
"The code to create the "someoption" option in the example program is rather verbose. I encourage the doclet team to explore supporting coding patterns similar to those enabled by the SupportedAnnotationTypes, SupportedOptions, and SupportedSourceVersion annotation types which can be used on annotation processors. In brief, the utility AbstractProcessor class can read annotations on concrete subclasses and act on that information. This cut down greatly on annotation processing boilerplate which we suffered through with apt. 
Digressing a bit, to adopt the AbstractDoclet pattern and annotations, here's what a doclet might look like

@DocletName("Fred")
@DocletOptions({@DocletOption(count=1, name="Bob", ...)})
@SupportedSourceVersion(RELEASE_9) // Use existing annotation from javax.annotation.processing
@DefaultLocale("ENGLISH", "US",) // Map this to one, two, and three arg Locale constructors
public class Joe_s_Doclet extends AbstactDoclet {
  @Override
  boolean run(Environment env) {...}


 // Code from the superclass handles returning the name, supported source version, etc.
} "

Jon's suggestions:
"The impl for AbstractDoclet.getName could be the simple name of the class

@Override
public String getName() {
     return getClass().getSimpleName();
}"