Created attachment 107056 [details]
stacktrace

How exactly did you get the build on which this happened? Could you please attach ${INSTALL_DIR}/java/modules/org-netbeans-modules-java-hints.jar? Thanks.

The code reads the hint description from the layer. The code that reads the description from the layer apparently sees that the hint1 method should be used, but that has been renamed recently. Clean build should produce the correct layer. So possible causes include a not-clean build, or the layer-cache bug. Without the org-netbeans-modules-java-hints.jar, we cannot even guess if any of these is more likely or if there is a possibility of another problem.

Attached module as requested

Created attachment 107728 [details]
module

Created attachment 107729 [details]
stacktrace

It appears that the module is a product of an incremental build - I would not recommend using such builds for production work.

It appears that the LayerGeneratingProcessor is not correctly deleting the entries from the layer. When I did this:
-put a Test.java into org.netbeans.modules.java.hints.bugs in java.hints, with content:
----------
package org.netbeans.modules.java.hints.bugs;

import org.netbeans.modules.java.hints.jackpot.code.spi.Hint;
import org.netbeans.modules.java.hints.jackpot.code.spi.TriggerPattern;
import org.netbeans.modules.java.hints.jackpot.spi.HintContext;
import org.netbeans.spi.editor.hints.ErrorDescription;

@Hint(category="jdk")
public class Test {

    @TriggerPattern("")
    public static ErrorDescription t(HintContext ctx) {
        return null;
    }
}
-------------
-enhanced the Bundle.properties with required keys:
DN_org.netbeans.modules.java.hints.bugs.Test=X
DESC_org.netbeans.modules.java.hints.bugs.Test=X
-built the project (F11)
-changed the method name to t2, built again
-the resulting generated-layer.xml contains metadata for both methods, which is incorrect

I do not think that the JavaHintsAnnotationProcessor can do more than it is doing now: when it calls LayerGeneratingProcessor.layer it provides the corresponding TypeElement, so the LGP should delete the obsolete entries.

There are several possible cases that can arise when LayerBuilder is used during an incremental build:

1. The layer entry - identified by SFS path - has not been produced before. So it should be created.

2. The entry has been produced before by the same class, and is produced again. It should be overwritten.

3. The class produces some entries, but not all of what was produced before. The older entries should be removed (newer ones falling under #1 or #2). A special case is that the class is scanned by one or more (LGP-based) APs but produces no entries at all; another is that the paths of one or more entries have changed (as in this bug I think).

4. The class produced some entries before, but is no longer scanned by any AP (generally due to all layer-generating annotations being deleted), though some APs are active on other classes. The old entries should be removed. A special case is that a class has been renamed.

5. One or more classes produced some entries before, but there are no longer any classes in the source root being scanned by any AP. The old entries (if not the whole layer) should be removed.

#1 and #2 are common and already work.

#3 is probably not hard to fix; LayerBuilder already records (in a comment) the originating element (OE), assuming there is exactly one, so close() ought to be able to delete prior entries which were not overwritten.

#4 is probably fixable with some more work; need to track everything written by any AP from any OE.

#5 cannot be fixed with current 269 implementations, since LGP will not be called at all.

I do not consider this a high priority; you should do a clean build of a module if making major structure changes, and when creating a full build you should always 'ant clean' first. (If you fail to do so, and run across LinkageError's or ClassNotFoundException's or NoSuchMethodException's, please do not bother reporting them.)

Just do clean build.

FWIW #5 might be collapsed into the #4 case with a special processor marked @SupportedAnnotationTypes("*").