Public API for programmatic registration of Taglet?

[Martin Desruisseaux]

Hello Jonathan

Thanks for your reply. Indeed, I understand that adding new API can be
tricky. If it is desired to avoid that path, modifying the
Taglet.init(…) specification the way you rephrased would help a lot.
Alternatively, another way to work without any specification change may
be to allow StandardDoclet.run(...) to accept arbitrary
DocletEnvironment without throwing ClassCastException.

    Regards,

        Martin


Le 18/04/2018 à 18:37, Jonathan Gibbons a écrit :

> Martin,
>
> You are (regrettably) on the bleeding edge here with this use of the
> recent new Doclet API.
>
> I would somewhat rephrase your first bullet, to reflect the intent of
> the API
>
> * Whatever the doclet, the doclet given in Taglet.init(...) method
> should be the user doclet, whether specified explicitly or by default
>
> Given that redefinition, the behavior you describe can reasonably be
> described as a bug.  This would require a minor spec change of the
> doclet parameter: "doclet - the doclet that instantiated this taglet"
>
> It is true that there is no public API (except for option support) on
> StandardDoclet to access some of the features of the standard doclet. 
> And, I don't think we should go all the way with methods to access all
> the individual features. But, there is precedent in other similar APIs
> for adding methods to provide instances of objects that might
> otherwise be created in problematic classloaders. The most notable
> case is the ability to provide instances of annotation processors to
> javac [1]
> The problem in this case would be the specification of such a method.
> While it would be easy to write "Adds a custom tag." the order of the
> calls has a visible impact on the generated documentation that would
> be harder to specify and/or provide full control.
>
> -- Jon
>
> [1]
> https://docs.oracle.com/javase/9/docs/api/javax/tools/JavaCompiler.CompilationTask.html#setProcessors-java.lang.Iterable-
>
>
>