I disagree. If the annotation processing would be enabled by the default query, it would not allow to disable the annotation processing for projects that do not define any APQuery. If there would be inefficient AP on the classpath of such project, it would slow down whole IDE, and there would be no way whatsoever to fix that. That would mean that the IDE would perform worse in some situations than 6.8. The current state is no worse than the NB6.8 state, and allows to use APs for project types that have proper customizers to enable annotation processing.

(In reply to comment #1)
> If the annotation processing would be enabled by the default query,
> it would not allow to disable the annotation processing for projects that do
> not define any APQuery.

So, they (or any third party) can define a query impl that disables AP.

> If there would be inefficient AP on the classpath of such project

Then any builds of the project would be slow too. Which is why you would either fix that AP to be faster, or disable running it (whether in project config or simply by making it not be registered for default discovery). Why should the IDE's internal compiler intentionally behave differently than the external compiler?

> it would slow down whole IDE, and there would be no way
> whatsoever to fix that.

Of course there would - disable AP in that project, if the project type provides an AP impl, or supply an alternate (global) AP impl if it does not.

> That would mean that the IDE would perform worse in
> some situations than 6.8.

And better in some situations than 6.8.

(In reply to comment #2)
> (In reply to comment #1)
> > If the annotation processing would be enabled by the default query,
> > it would not allow to disable the annotation processing for projects that do
> > not define any APQuery.
> 
> So, they (or any third party) can define a query impl that disables AP.

The same holds currently about a query impl that enables AP, doesn't it?. 

> 
> > If there would be inefficient AP on the classpath of such project
> 
> Then any builds of the project would be slow too. Which is why you would  
either

Performance of command line project build is not so critical as performance of IDE features (e.g. code completion), or is it? Annotation processor that runs for 1 second may be OK for a command line build, but is certainly not OK for IDE features.

> fix that AP to be faster, or disable running it (whether in project config or
> simply by making it not be registered for default discovery). Why should the
> IDE's internal compiler intentionally behave differently than the external
> compiler?
> 
> > it would slow down whole IDE, and there would be no way
> > whatsoever to fix that.
> 
> Of course there would - disable AP in that project, if the project type
> provides an AP impl, or supply an alternate (global) AP impl if it does not.

Well, I meant no way for the user. But, if the user can provide a global APQuery impl that disables AP, he/she can currently provide a global APQuery impl that enables it. I see no principal difference in this regard.

> 
> > That would mean that the IDE would perform worse in
> > some situations than 6.8.
> 
> And better in some situations than 6.8.

Well, this is balancing costs and benefits. I (as the one who is supposed to be the first evaluator of bugs on java.source, where "bugs" about this would be filled) think that the costs are much higher than benefits. Note that even not all NetBeans' AP are fast - seems that Schema2BeansProcessor is quite slow (there is a profiler snapshot where it takes 18% of indexing time!) - bug will be reassigned soon.

(In reply to comment #3)
> Annotation processor that runs
> for 1 second may be OK for a command line build, but is certainly not OK for
> IDE features.

It is OK during classpath scanning. (Obviously not during code completion, but this is a separate function in Processor.) Much better than having the source root be marked erroneous - or, nearly as bad, marked correct when it would not in fact be buildable.

> seems that Schema2BeansProcessor is quite slow

Again, this is a problem with schema2beans, not java.source. It is preferable to wait an extra few seconds during initial scanning to make sure the generated sources are correctly honored by the editor, than to waste much more time later trying to figure out why you have error badges everywhere.

(In reply to comment #4)
> (In reply to comment #3)
> > Annotation processor that runs
> > for 1 second may be OK for a command line build, but is certainly not OK for
> > IDE features.
> 
> It is OK during classpath scanning. (Obviously not during code completion, but
> this is a separate function in Processor.) Much better than having the source

This is not a separate function - "process" method of APs needs to be run while editing in editor (otherwise you would not get the errors in the editor) and also when invoking CC (otherwise "clever" APs like Lombok would not work). getCompletions is a separate function, but is not important in this regard.

Note that even enabling AP by default still will be wrong in many cases, as the command line may contain processors list, -proc:none or processor path. All this can easily lead to incorrect error badges, and project support is still needed to resolve this. So add APQuery to project types is the best solution, IMO.

> root be marked erroneous - or, nearly as bad, marked correct when it would not
> in fact be buildable.

(In reply to comment #5)
> This is not a separate function - "process" method of APs needs to be run while
> editing in editor

Right, but only when the AP is active on some annotations in that source file (or when it specifies "*").

> Note that even enabling AP by default still will be wrong in many cases, as the
> command line may contain processors list, -proc:none or processor path.

Of course, which is why project types can and will specify an APQI that reflects whatever they know about how the command line will work. I am talking about the fallback APQI which is returned when no more specific information is available - for example, for sources which are not contained in any project. For other queries we attempt to make this match the default behavior of the compiler, i.e. the behavior when no special compiler options are passed.

(In reply to comment #6)
> > Note that even enabling AP by default still will be wrong in many cases, as the
> > command line may contain processors list, -proc:none or processor path.
> 
> Of course, which is why project types can and will specify an APQI that
> reflects whatever they know about how the command line will work. I am talking
> about the fallback APQI which is returned when no more specific information is
> available - for example, for sources which are not contained in any project.
> For other queries we attempt to make this match the default behavior of the
> compiler, i.e. the behavior when no special compiler options are passed.

Well, in theory, the return value of annotationProcessingEnabled() should not matter in this case - when one invokes:
javac <some-java-source>
(i.e. without any compiler options), there is no -classpath and no -processorpath, and so no APs are run.

But, in IDE, the behavior deviates from the default behavior - the fallback compilation classpath is an auxiliary classpath which contains virtually everything the IDE knows about. So, if the APs would be enabled in this case, "all" APs would be run, which is different from the default behavior of javac when no options are passed to the javac.

(In reply to comment #7)
> if the APs would be enabled in this case,
> "all" APs would be run, which is different from the default behavior of javac
> when no options are passed to the javac.

True, this would be the wrong default.