Public API for programmatic registration of Taglet?

[Jonathan Gibbons]

In the general case, they cannot share classloaders ...

1. If you're loading user-defined taglets into the system-defined 
Standard Doclet, they probably should not be in the same class loader.

2. The user may use the -tagletpath option to specify a different 
searchpath for taglets.

You did qualify your question about whether they are defined in the same 
JAR file, but that raises a chicken-and-egg question, and still doesn't 
address the corner-case of differently ordered taglet paths and doclet 
paths.

Ideally, I'd like to say that the taglet classloader should be one that 
delegates to the doclet classloader, but that does not appear to be 
practical without fixing some shortcomings elsewhere in other API 
(JavaFileManager.getClassLoader).

I suspect the best answer will be to add the method you suggested 
earlier, to register a Taglet directly with the custom doclet, to 
side-step the classloader issues. That will need a bit more investigation.

-- Jon




On 4/18/18 3:24 PM, Martin Desruisseaux wrote:
>
> This is fine, thanks for investigating. Would the following 
> implementation adjustment be also acceptable?
>
>   * If the Doclet and the Taglet are defined in the same JAR file,
>     then they share the same URLClassLoader.
>
> I'm not 100% sure that this is the right thing to do. But it would be 
> helpful (while not indispensable) in the case that I described (doclet 
> and taglet sharing common custom data structures).
>
>     Martin
>
>
> Le 18/04/2018 à 20:39, Jonathan Gibbons a écrit :
>
>> OK, we can't easily accept arbitrary subtypes of DocletEnvironment, 
>> without embarking on a bunch of changes to other public API.
>>
>> This means the correct solution here is that Taglet.init should be 
>> called with the "user doclet" (which we expect people to provide 
>> subtypes of) and the system-provided DocletEnvironment (which we do 
>> not expect people to subtype.)
>>
>> The spec change here (for the @param doclet) is not a material 
>> change; it is a clarification of the original intent. We just need to 
>> think of the best words to describe the usage without getting into 
>> the internal details of StandardDoclet delegating to HtmlDoclet.
>>
>> -- Jon 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/javadoc-dev/attachments/20180418/a97ac76b/attachment-0001.html>