Library Javadoc not performed from source code context menu

[ms270169]

Apache NetBeans version

Apache NetBeans 13

What happened

After adding a library (via menu Tools->Libraries) and configuring javadoc setting, the Javadoc is properly opened in browser when selected via Project Browser -> Libraries -> Show Javadoc. But if Javadoc should be shown via context menu "Show Javadoc" in source code, the status message "Cannot perform Show javadoc here" is shown.

Class is proper imported, because building the project and "Navigate -> Go to source" works as expected.

How to reproduce

No response

Did this work correctly in an earlier version?

Apache NetBeans 12.3 or earlier

Operating System

Ubuntu 22.04

JDK

openjdk version "17.0.2" 2022-01-18

Apache NetBeans packaging

Apache NetBeans binary zip

Anything else

No response

Are you willing to submit a pull request?

No

Code of Conduct

Yes

[ms270169]

I made some further investigations with Google Gson library. Javadoc from source code works with Gson 2.8.6, and does not work with Gson 2.9.0.

I found out the very strange fact, that it does not matter on javadoc file (or folder), it depends on the library jar file.

There are indeed structural differences inside the library file gson.jar:

• version 2.8.6 (good version): file module-info.class on root but no folder versions
• version 2.9.0 (bad version): no file module-info.class on root but a folder META_INF/versions/9 which contains the file module-info.class

[ms270169]

I have now modified gson.jar by copying META-INF/versions/9/module-info.class to /module-info.class inside the jar file (which is a zip archive). After this modification Netbeans 13 is able to open Javadoc also from source. At the moment I don't know who is makeing the mistake (the gson library or Netbeans 13).

[matthiasblaesing]

I can reproduce this with a simple Maven Projekt: mavenproject1.zip

The result is:

In the log it can be observed:

FINE [org.netbeans.api.java.source.ElementHandle]: Resolving element kind: METHOD
FINE [org.netbeans.api.java.source.ElementHandle]: Calling getTypeElementByBinaryName: signature = com.google.gson.Gson
FINE [org.netbeans.api.java.source.ElementHandle]: All resolvings failed. Returning null.
INFO [org.netbeans.api.java.source.ElementHandle]: Cannot resolve: ElementHandle[kind=METHOD; sigs=com.google.gson.Gson newBuilder ()Lcom/google/gson/GsonBuilder; ]

it seems, that there is something wrong with the compiler task that is used to scan the classpath:

FINE [org.netbeans.modules.java.source.usages.ClassFileUtil]: Calling createExecutableDescriptor: ExecutableElement = newBuilder()
FINE [org.netbeans.modules.java.source.usages.ClassFileUtil]: Result of encodeClassNameOrArray = com.google.gson.Gson
FINE [org.netbeans.modules.java.source.usages.ClassFileUtil]: Result of createExecutableDescriptor = [com.google.gson.Gson, newBuilder, ()LGsonBuilder;]

The return type looks broken. It is missing the package portion. I had a closed look at the beginning of org.netbeans.modules.java.source.usages.ClassFileUtil.createExecutableDescriptor(ExecutableElement). The value of ee.getReturnType is: Type$errorType. So the question is: Why does the task fail to resolve the return type?

@jlahoda sorry to bother you again, but know the compiler infrastructure best, maybe you have an idea where this breaks down?

[jlahoda]

@matthiasblaesing, sure, I'll take a look, but it may unfortunately take a week or so before I get to it. Sorry for that.

[matthiasblaesing]

@jlahoda thank you, no rush.

[matthiasblaesing]

@jlahoda I had another look at this an dnoticed, that there is a strange message:

WARNING [org.netbeans.modules.java.source.parsing.JavacParser]: ClassPath identity changed for AbstractFileObject@3a8454fe[com/google/gson/Gson.java], class path owner: null original sourcePath: /home/matthias/.m2/repository/com/google/code/gson/gson/2.9.0/gson-2.9.0-sources.jar new sourcePath: /home/matthias/.m2/repository/com/google/code/gson/gson/2.9.0/gson-2.9.0-sources.jar

Maybe this can shed some light on the problem?

[jlahoda]

I tried to look at this twice in the past, but wasn't so far able to find out the problem. I'll continue searching.

[jlahoda]

So, I may have an idea on what's the real reason. I've put a prototype of a fix here: https://github.com/jlahoda/netbeans/tree/NETBEANS-4044

I'd appreciate if anyone would be willing to try/verify it helps.

Thanks!

[matthiasblaesing]

@jlahoda thank you! I build your branch and it looks great to me. I used my demo project referenced above (gson-2.9.0). With current master I did not get javadoc for Gson#newBuilder and when invoking "Go to source" I'm jumped to the head of the source, not the method definition. Both problems are fixed by your patch (i.e. I get javadoc and "Go to source") works correctly and jumps me to the actual method definition. So to me this looks like it fixes this issue.

@ms270169 I pushed a build of @jlahodas branch here: https://doppel-helix.eu/NetBeans-dev-dev-e0ef39536ddd75096e61dc7469790c8e33048421-release.zip

[neilcsmith-net]

I think this issue is partly fixed by #4391 but Show Javadoc only seems to work in the example project from @matthiasblaesing if it's made into an explicit module. @jlahoda is there an API to infer a module name from an Element if it is on the classpath?

[neilcsmith-net]

This is partly fixed in NB15. Still aspects to look at in NB16 timeframe. Bumping the milestone.