Bug 236431

Xhtml files are not supported in Action Items by default. For java files, as far as I know hints were never in Action Items. Reassigning to Java/Hints for further evaluation.

Geertjan blogged about it at https://blogs.oracle.com/geertjan/entry/towards_a_centralized_dashboard_for
and provided a proof-of-concept plugin at http://plugins.netbeans.org/plugin/50925/?show=true

this is not a defect, but rather an enhancement. Hints and their evaluation were never designed to be dynamic as action items are;


re. markiewb: there are a lot of problems presenting Hints in action items, one of them is UI consistency - while there are actions which could be applied on hints (i.e. run a quickfix, disable entire category, configure hint), such actions are not available for TODOs. 

Another one is data consistency: a [java] hint is often affected not just by file contents, but also classpath contents, other classes. Similar for PHP hints, where included files play some role. While TODOs refresh automatically, hint-based action items would remain partially up-to-date (those that are lucky to be affected mainly by one file contents) and partially obsolete (i.e. change add @NotNull annotation on the target method, and stil see NPE hint in the caller)
Not to mention that there are hints like metrics or structure analysis (look in IDEA, not NetBeans, we are not that far yet) which make only sense to run on demand.

[a personal opinion follows]
I understand and applaud the blogpost bottom line to attract Eclipse users to NetBeans. But as blogposts usually do, touches just the surface of the area and the developer's daily boring details are not visible from that high level. I would prefer to give the Eclipse (and NetBeans) users better tools, not just an cozy familiar environment that would just behave inconsistently by definition. I believe that the developer need to trust their tools in order to be effective at their programming work. So if the tool's output is partly current and partly outdated, it's probably worse than no output at all. 

Still I am thinking about a migration path for people used to Eclipse, that would allow them to adapt to (IMHO) more effective work style or at least keep them in their habits with limits that could be understood and counted with.

Of course one could invent a system where metadata is generated for symbols and their dependencies and change in metadata would trigger re-validation of other files. But this quite sophisticated system is likely to be slow (ie modification of the called method might revalidate dozen of files - dozen of parsing request) and sophisticaated means also error-prone and more burden on hint implementors. I believe the time would be better invested in architectural hints that are not present in NetBeans at all.

FYI: Here is another approach from jlahoda

http://plugins.netbeans.org/plugin/54834/java-hints-to-actions-window

(In reply to markiewb from comment #4)
> FYI: Here is another approach from jlahoda
> 
> http://plugins.netbeans.org/plugin/54834/java-hints-to-actions-window

Yes, this is a simple implementation of the enhancement, however it does not refresh "precisely". So for example, if the action item warns you that a bundle key used in getMessage() is not present in the bundle, it does not disappear even though you add the key to the bundle and save. You need to modify / save the file where the getMessage() is.

Such simple implementation is easy, and performant enough (just another presentaton of file annotations) but does not work quite as other TODOs.