Analyze Javadoc not working on modular project

[pedro-w]

Apache NetBeans version

Apache NetBeans 26

What happened

In a modular project it appears that the Analyze Javadoc function (in the tools menu) does not work. Nothing appears in the Analyze tab. It does work as expected (showing missing doc entries) for a non-modular project.

Language / Project Type / NetBeans Component

Java Ant Modular Project

How to reproduce

• Create a new Java Modular Project with Ant.
• Create a new module
• Create a new package in that module
• Create a new class in that package
• Delete the auto-generated javadoc comments for the class
• Select Tools | Analyze Javadoc

(also see example project on GitHub: pedro-w/analyze-javadoc )

Nothing appears in the Analyze tab. Would expect items to appear there offering to add missing comments to the NewClass class definition.

Did this work correctly in an earlier version?

No / Don't know

Operating System

Windows 11, amd64

JDK

JDK24 built into NB 26

Apache NetBeans packaging

Apache NetBeans provided installer

Anything else

Nothing relevant seen in the IDE log. May be related to the package being shown in the IDE as a private package, even though it is exported from the module?

Are you willing to submit a pull request?

No

[pedro-w]

It works for Maven modular projects (if set up so that each Maven module is also a JPMS module), in the sense that double-clicking a module in the parent project opens up that module as a separate project, and Analyze Javadoc will work on the sub-project.

[pedro-w]

I've done a bit more looking at this, and I believe it is down to way that NB checks for accessible classes (accessible in the sense of public / private etc). The Javadoc hint does not report missing doc comments if the element in question is not accessible. There is an extra code path for understanding accessibility in modular projects (by parsing the module-info.java). There appears to be a bug that anything in a module is marked as being not accessible. I think this is down to the following (cc is a org.netbeans.api.java.source.CompilationController atteched to the module-info file here)

https://github.com/apache/netbeans/blob/2c07bda77e5b22ab3d601ea39b33f74a4892b2a0/java/java.api.common/src/org/netbeans/modules/java/api/common/queries/ModuleInfoAccessibilityQueryImpl.java#L268-L281

I think it's supposed get the one and only TypeDecl from the compilation unit, which will be the module {} block. Unfortunately getTypeDecls does not return the module block, there is another function getModule for that.

I applied this simple patch and it made my example project (above) work correctly.

diff --git a/java/java.api.common/src/org/netbeans/modules/java/api/common/queries/ModuleInfoAccessibilityQueryImpl.java b/java/java.api.common/src/org/netbeans/modules/java/api/common/queries/ModuleInfoAccessibilityQueryImpl.java
index 65d735c600..288ded64df 100644
--- a/java/java.api.common/src/org/netbeans/modules/java/api/common/queries/ModuleInfoAccessibilityQueryImpl.java
+++ b/java/java.api.common/src/org/netbeans/modules/java/api/common/queries/ModuleInfoAccessibilityQueryImpl.java
@@ -266,8 +266,9 @@ final class ModuleInfoAccessibilityQueryImpl implements AccessibilityQueryImplem
                 src.runUserActionTask((cc) -> {
                     cc.toPhase(JavaSource.Phase.RESOLVED);
                     final CompilationUnitTree cu = cc.getCompilationUnit();
-                    if (cu.getTypeDecls().size() == 1 && cu.getTypeDecls().get(0) instanceof ModuleTree) {
-                        final ModuleTree mt = (ModuleTree) cu.getTypeDecls().get(0);
+                    // Module tree or may be null
+                    ModuleTree mt = cu.getModule();
+                    if (mt != null) {
                         final ModuleElement me = (ModuleElement) cc.getTrees().getElement(TreePath.getPath(cu, mt));
                         if (me != null) {
                             for (ModuleElement.Directive directive : me.getDirectives()) {

However the whole hint system is very complicated code so not sure if this is correct or may have implications elsewhere. Any comments welcome.

ps. AFAICS it's not (directly) related to Ant.

pps. the module where this is, Java Common Project API, has Source level 1.8, can this be upgraded?

[pedro-w]

As a bonus the IDE now shows the package with an unlocked padlock icon as it is exported from that module.

(left: without patch, right: with patch)

[pedro-w]

Follow up:

https://bugs.openjdk.org/browse/JDK-8255464

The API to access the module was not available in JDKs 9 to 16 inclusive, which may be an issue for older JDK platforms.

[edit] - looking at the diff from that bug report, it appears that getTypeDecls did return the module definition from JDK9 up to JDK16 but doesn't any more from JDK17 onwards.

[homberghp]

I will try to turn it into a PR.

[homberghp]

As far as the Java source level is concerned, I think you can upgrade it to 17, as that is the minimum build system and runtime system for NetBeans at the moment (NetBeans 26). In project.properties change line 16 'javac.source=1.8' to 'java.release=17'

You would need that, because the getModule() method has the annotation @since 17

[homberghp]

Some tests fail in this module. I will report that. It is a pity that this particular file has no tests .

Could you supply a MWE (minimal working example) attached as a zip, so we can use that as reference? Then we can complete the findings and maybe use this as an initial test case.

[pedro-w]

I believe I have solved this and another case where the cause was the same.