Is there any estimate as to when this will be addressed?

I'd like to test this fix in our environment sooner than later.

I will hopefully attach a diff for api review today.

Created attachment 98773 [details]
Diff file

The freeform-project-java-3.xsd has changed to support AP. The classpath of type processor has moved into a new compilation unit section (annotation-processing) which supports also source-output, triggers, explicit processors and processor options.
The example of the cu with annotation-processing element:

<compilation-unit>
   <package-root>src</package-root>
    <classpath mode="compile">lib/TestProcessor.jar</classpath>
    <built-to>build</built-to>
    <source-level>1.6</source-level>
    <annotation-processing>
        <scan-trigger/>            <!-- AP invoked in initial scan and after file save->
         <editor-trigger/>         <!-- AP invoked after each change in editor (may slow down edits, for j2seproject not enabled by default)->
         <source-output>gen-src</source-output>     <!--where are the AP generated sources, the sources should not be a part of any cu! -->
         <processor-path>lib/TestProcessor.jar</processor-path> <!-- Not needed as the processor is on comple cp -->
         <processor-option>
             <key>test_ap_key</key>
             <value>test_ap_value</value>
         </processor-option>
         <processor-option>
             <key>another_test_ap_key</key>
             <value>another_test_ap_value</value>
         </processor-option>
     </annotation-processing>
</compilation-unit>

Changed the freeform-project-java-3.xsd to support the APQuery.Result.

Looks nice overall.

So the processor-path replaces classpath mode="processor"?

>So the processor-path replaces classpath mode="processor"?
Yes

Looks OK to me.

Thanks,
I will integrate it tomorrow.

Fixed in jet-main a3754e9b1d3a

Integrated into 'main-golden', will be available in build *201005132200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/
User: 
Log:

Seems to work alright!

OK.
Thanks for your help!

On a somewhat unrelated note, I made the mistake of trying to use go-to-type in the midst of scanning.  I actually got a type in the dialog, so I selected it.  The UI then stopped handling any/all input for just over an hour.  I almost killed NetBeans during this, but I decided to see if it would snap out of it.  It did, but I'm not sure if it would ever be acceptable to wait an hour for it to do so.

This goes back to the old issue -- scanning should not block any actions and should incrementally build/update the scan/completion database.

If you have a tread dump please attach it to this issue or create a new one. Several successive thread dump are even better to find out possible live lock. It may be related to deadlock and in some cases only large delay in FileSystems - issue #185900 which is now fixed. But I am not sure.

> scanning should not block any actions and should incrementally build/update the scan/completion >database
I am working on prototype of this in my free time. There are several API incompatibilities, the biggest problem is 2 concurrent threads doing IO, which is not so bad when parts of caches are in memory -J-Djava.index.useMemCache=true. Anyway the Go To Type (when the file is found) should not be blocked by scanning even today, when the IDE is busy with scanning it should just open the file at the beginning.