Update JavaIndex when a file without its project is opened

[JaroslavTulach]

• while working on ProjectsRootNode I found following error:

• there are errors in the source code of ProjectsRootNode even there shall be none
  • the problem is that there is no open project
  • then the system doesn't create Index for ide/projectui/src and then it cannot find co-located files
• @lahodaj suggested to use

  netbeans/java/java.source.base/src/org/netbeans/modules/java/source/classpath/SourcePath.java

  Line 47 in 1336aa1

  private static final boolean NO_SOURCE_FILTER = Boolean.getBoolean("SourcePath.no.source.filter"); //NOI18N

• with -J-DSourcePath.no.source.filter=true it all works correctly
  • however Jan warns, that such a change could hurt IDE performance
• as such I was seeking for another fix
• explicitly refresh the index when it is not yet initialized

[JaroslavTulach]

• this change does not create any new indexes
• it only detects that there is a not yet initialized index and refreshes it
• as such putting a file into $HOME doesn't make any difference, @lahodaj - there is no index, so we don't referesh it

[lahodaj]

So, I dag deep(er), a this is what I've found:

starting from a clean userdir:

• I go to Tools/Plugins and manually enable "Developing NetBeans" (we'll get to this later)
• then I open ide/projectui/src/org/netbeans/modules/project/ui/ProjectsRootNode.java. There's indexing happening. No errors
• then I restart the IDE
• there are errors in ProjectsRootNode.java

The reason for this behavior is that there is:
https://github.com/apache/netbeans/blob/master/java/java.source.base/src/org/netbeans/modules/java/source/classpath/SourcePathCheck.java
which registers "unknown" roots. But, it uses !JavaIndex.hasSourceCache(url,false) (

netbeans/java/java.source.base/src/org/netbeans/modules/java/source/classpath/SourcePathCheck.java

Line 76 in 1336aa1

!JavaIndex.hasSourceCache(url,false) &&

), and as a consequence the registration only happens if there's no index whatsoever. I.e. it happens on the first run, but after the restart, the index does exist, and the registration is skipped.

This is what the patch here helps with; but it would be IMO hopefully cleaner to use !JavaIndex.hasSourceCache(url,true) instead.

This is, of course, only partial solution - and maybe, for your case, this partial solution is OK, then please go ahead with the false -> true change.

The limitations is that there needs to exist a project for the file (the very next line is FileOwnerQuery.getOwner(url.toURI()) != null). Hence:

• if I don't go the Tools/Plugins and don't enable apisupport, there's no project for the file, and everything is red. For me, at least. Because this is a projectless source root now.
• if I copy e.g. openide.util.lookup/src into a directory (without the project metadata), and open a file from this directory, I still see the errors. There no project and hence no index created by SourcePathCheck.

[jtulach]

Thanks for review @lahodaj and yes, you are right steps to reproduce were not exact enough.

Steps to Reproduce

Let's reproduce with 915296a. This time without ergonomics.

• let's build it $ JAVA_HOME=/jdk-21 ant build -Dcluster.config=basic
• let's clean previous debris and ergonomics: rm -rf nbbuild/netbeans/ergonomics/ nbbuild/testuserdir/
• let's run it: netbeans$ JAVA_HOME=/jdk-21 ant tryme -Dcluster.config=basic
• let's open internal terminal and netbeans ide/projectui/src/org/netbeans/modules/project/ui/ProjectsRootNode.java
• await parsing finished
• there should be no errors and code completion shall work
• now restart the IDE
• there should be errors when referencing ProjectChildren line 113

The errors are there with 915296a.

Fix

With a867080 the errors are gone, exactly as @lahodaj predicted:

The limitations is that there needs to exist a project for the file (the very next line is FileOwnerQuery.getOwner(url.toURI()) != null).

Yes, that's perfectly fine limitation. Let's fix the ergnomics misbehavior in some other PR. Thanks for your suggestion. a867080 is much cleaner fix than c3f98c6 even it does basically the same (as we discussed yesterday), but c3f98c6 is too brute force.

[jtulach]

• @lahodaj, can you re-review now with your a867080 in?
• do you want me to write a test?
• would you suggest a test to copy and alter?