Using 7.4RC1 with a Maven JSF project the Action Items window does not show any hints or warnings that are in xhtml and java files. Filters are set to "show all" and it does not matter if action items is set for the current file, project or everything.
It does successfully show my TODOs and a few specific warnings. It shows warnings from CSS files. It will show errors in java files. The only java warning it has shown (that I've seen anyway) is specifically:
com.sun.rowset.CachedRowSetImpl is internal proprietary API and may be removed in a future release
However, it is not showing other warnings (that exist in the editor window) such as:
Convert to try-with-resources
The assigned value is never used
Missing @throws tag for java.sql.SQLException
and in xhtml files:
Unknown resource bundle key "whatever"
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.