Not the source of truth. Java might perform certain transformations, meaning that we don't have the full picture when parsing the source and will have to replicate those transformations in jnigen. Because at the end of the day, what matters for the correctness of a JNI program is the bytecode and not the source.
Cannot be used for Kotlin. So we'll have to create another solution for Kotlin as well.
We don't always have access to the sources. Or "complete" sources.
Having to maintain two (or more for Kotlin) parsers is an engineering overhead.
The only real benefit of using doclet is to get the names of the arguments and the java doc for Java sources when they are available. But javadoc is almost always available.
Solution
[ ] Instead we create a javadoc parser to augment information such as argument names and documentations
Rationale
Problems with doclet:
The only real benefit of using doclet is to get the names of the arguments and the java doc for Java sources when they are available. But javadoc is almost always available.
Solution