-
Notifications
You must be signed in to change notification settings - Fork 19
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Resolves #61. Inherit missing javadoc components from overridden meth…
…ods (#64) Closes #61. Inherit missing javadoc components from overridden methods if they exist. This adds javadoc from the overridden method in super class or interfaces if none is present on the declared method at runtime. When a class is extended and/or multiple interfaces are implemented with the same signature priority returned by the super-class first then the interfaces in the order they are declared as is done by the javadoc command line tool One of the potentially main issues I was not able to figure out was how to preserve the parameter order when inheriting java doc when some of the params are on the overriding method and some on the overridden. We don't have guaranteed access to the param names at runtime which makes it difficult to discern true order. Currently the inherited params are just added to the end of the list. If the java doc is not complete then the missing parts are inherited from the overridden methods as described here https://docs.oracle.com/en/java/javase/17/docs/specs/javadoc/doc-comment-spec.html. When loading a class javadoc all the methods are properly populated with inheritance. When loading just method javadoc only the necessary javadoc are loaded. I changed the class javadoc to use a map in order to have more efficient method lookup. I left the getters to return list for the various components and the order is preserved from how they are inserted. It may be better to at some point change the return type to a collection as it can be a strict view, but at the moment this was not done in case dependent code expects a list. Also something to consider is that in the annotation processor we erase all the type parameters so the param types of methods are limited to their bounds which can be seen on the generic method in Documented Class. However the javadoc tool actually preserves the generic type and bounds. This did not cover the case of adding the javadoc from protected fields or parsing @ inheritdoc as I think these are a separate concern. Note this implementation does not require @ Override to be present on the method. Note that when you generate javadoc for the VeryComplexImplementation it actually does not follow the algorithm provided [in the link.](https://docs.oracle.com/en/java/javase/17/docs/specs/javadoc/doc-comment-spec.html. It actually performs recursive search on the superclass first resulting in inheriting the javadoc for the fling method from DocumentedInterface rather than CompetingInterface as would be expected if the algorithm ran as described. So likely the order priority is something that changes with java versions unfortunately
- Loading branch information
Showing
18 changed files
with
1,029 additions
and
183 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
21 changes: 21 additions & 0 deletions
21
...ime-javadoc-scribe/src/test/resources/javasource/bar/OverridingClassInAnotherPackage.java
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,21 @@ | ||
package javasource.bar; | ||
|
||
import java.util.List; | ||
import javasource.foo.DocumentedClass; | ||
|
||
|
||
// I override methods of DocumentedClass with and without their own javadoc | ||
public class OverridingClassInAnotherPackage extends DocumentedClass<Object> { | ||
|
||
/** | ||
* Quick frobulate {@code a} by {@code b} using thin frobulation | ||
*/ | ||
public int frobulate(String a, int b) { | ||
throw new UnsupportedOperationException(); | ||
} | ||
|
||
// I have no javadoc of my own | ||
public int frobulate(String a, List<Integer> b) { | ||
throw new UnsupportedOperationException(); | ||
} | ||
} |
20 changes: 20 additions & 0 deletions
20
therapi-runtime-javadoc-scribe/src/test/resources/javasource/foo/ComplexImplementation.java
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,20 @@ | ||
package javasource.foo; | ||
|
||
import javasource.foo.OtherInterface; | ||
import javasource.foo.DocumentedInterface; | ||
|
||
public class ComplexImplementation implements DocumentedInterface<Integer>, OtherInterface<Integer> { | ||
// I have no javadoc of my own | ||
public boolean hoodwink(String i) { | ||
throw new UnsupportedOperationException(); | ||
} | ||
|
||
// I have no javadoc of my own | ||
public boolean snaggle(String i) { | ||
throw new UnsupportedOperationException(); | ||
} | ||
|
||
public boolean fling(Integer v) { | ||
throw new UnsupportedOperationException(); | ||
} | ||
} |
Oops, something went wrong.