On Mon, 6 Mar 2023 19:48:48 GMT, Pavel Rappo <[email protected]> wrote:
> Please review this explorative refactoring for VisibleMemberTable (VMT).
>
> This is the first round of refactoring for VMT. This round is about *method
> members*: declared (overriding and not) and inherited.
>
> During this work I gained some insight into internal workings of VMT, fixed
> what was feasible and left TODOs and FIXMEs for everything else. Leaving
> those comments might look untidy, but leaving them out is wasteful: they
> clearly mark issues that should be revisited in upcoming rounds of
> refactoring.
>
> As I see it today, the main issue with VMT is that implements complex and
> error-prone computations from Java Language Specification (JLS) by hand. For
> example, VMT interprets JLS rules for relations such as _inherits_,
> _overrides_ and _hides_. As one would imagine, sometimes VMT does it
> incorrectly. It would be better to eventually re-implement VMT using
> `javax.lang.model` as much as possible. Unlike that of `jdk.javadoc`, the day
> job of `javax.lang.model` is to provide JLS services.
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/MethodWriterImpl.java
line 311:
> 309: }
> 310: Contents contents = writer.contents;
> 311: var enclosing = (TypeElement) method.getEnclosingElement();
Wishlist for Language Model: default methods that return a narrower result type:
interface Demo {
...> Element getEnclosingElement(Element e);
...> default TypeElement getEnclosingElement(ExecutableElement ee) {
...> return (TypeElement) getEnclosingElement((Element) ee);
...> }
...> default TypeElement getEnclosingElement(VariableElement ve) {
...> return (TypeElement) getEnclosingElement((Element) ve);
...> }
...> }
```
-------------
PR: https://git.openjdk.org/jdk/pull/12887
