I think that would be a good improvement. Note that non-sealed classes are indicated as <any> as in https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/invoke/CallSite.html CallSite (Java SE 21 & JDK 21)<https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/invoke/CallSite.html> declaration: module: java.base, package: java.lang.invoke, class: CallSite docs.oracle.com /Per ________________________________ From: liangchenb...@gmail.com <liangchenb...@gmail.com> Sent: Friday, October 20, 2023 7:15 PM To: javadoc-dev@openjdk.org <javadoc-dev@openjdk.org>; Per Minborg <pminb...@openjdk.org> Subject: @sealedGraph showing exhaustiveness of hierarchy
Hello Per-Ake and developers, The @sealedGraph javadoc taglet that renders sealed classes hierarchy currently does not indicate the exhaustiveness of a hierarchy; for example, MethodHandleDesc may have non-DirectMethodHandleDesc implementations while StringTemplate.Processor.Linkage only has FormatProcessor implementations. Currently, javadoc distinguishes by adding a "(not exhaustive)" note after the permits list. Should @sealedGraph find a similar way to indicate non-exhaustiveness? Chen Liang
