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- > > >
