[ANN] Inspection Gadgets 1.0.2 for Pallada

Very cool. If you get me the sources, I'll get them them merged into the CVS repository JetBrains set up, as it looks like the handover will be starting soon.

--Dave Griffith

After the handover, will there still be opportunity for you
non-JetBrains inspection guys to add new inspections and correct newly
discovered bugs? Based on recent history the community seems much more
responsive than JetBrains, so I'm afraid that fixes and features will
end once JetBrains gets the handover.

Jon

Dave Griffith wrote:

Very cool. If you get me the sources, I'll get them them merged into the CVS repository JetBrains set up, as it looks like the handover will be starting soon.

--Dave Griffith

For fixes, I have no doubt that JetBrains will continue to show their current outstanding level of support as they go forward with IPP and IG. It looks as though there will already be JetBrains supplied fixes for both plugins in 2014, and from here on bug reports on either plugin should be done via Tracker items. For features, I consider both plugins very nearly feature complete. There aren't more than a handful of static analyses implemented in any commercial or open-source product that are not implemented in InspectionGadgets, and with only two recent exceptions (for<->while, for<->foreach) I haven't heard a worthy new intention suggestion for IPP in quite some time. If nothing occurs on these plugins but pounding out exception reports and adding a few JDK1.5 inspired features, I'll still consider them raving successes.

But to answer your question, there will be at least some period of overlap during which I will have access to the IPP and IG source trees and will be continuing to help with support. Mostly, though, I hope to be polishing off MetricsReloaded before beginning requirements gathering on my next plugin (tenative name: BattleSpace, a visualization plugin incorporating data from the dependency view, code inspections, and metrics to give developers high-quality "situational awareness" about the structure and quality of their code).

--Dave Griffith

Sorry, Dave, I'm not seeing the same outstanding level of support from
JetBrains as in the past, although I hope you are right. Your
perspective might be skewed by being the author of these plugins and
personally getting support on issues important to you. Good to know the
transitional plan.

Thanks,
Jon

Dave Griffith wrote:

For fixes, I have no doubt that JetBrains will continue to show their current outstanding level of support as they go forward with IPP and IG. It looks as though there will already be JetBrains supplied fixes for both plugins in 2014, and from here on bug reports on either plugin should be done via Tracker items. For features, I consider both plugins very nearly feature complete. There aren't more than a handful of static analyses implemented in any commercial or open-source product that are not implemented in InspectionGadgets, and with only two recent exceptions (for<->while, for<->foreach) I haven't heard a worthy new intention suggestion for IPP in quite some time. If nothing occurs on these plugins but pounding out exception reports and adding a few JDK1.5 inspired features, I'll still consider them raving successes.

But to answer your question, there will be at least some period of overlap during which I will have access to the IPP and IG source trees and will be continuing to help with support. Mostly, though, I hope to be polishing off MetricsReloaded before beginning requirements gathering on my next plugin (tenative name: BattleSpace, a visualization plugin incorporating data from the dependency view, code inspections, and metrics to give developers high-quality "situational awareness" about the structure and quality of their code).

--Dave Griffith

Dave Griffith wrote:

I hope to be polishing off MetricsReloaded before beginning requirements gathering on my next plugin (tenative name: BattleSpace, a visualization plugin incorporating data from the dependency view, code inspections, and metrics to give developers high-quality "situational awareness" about the structure and quality of their code).

Can't wait for BattleSpaces!

Cheers,
Jon

Very cool. If you get me the sources, I'll get them
them merged into the CVS repository JetBrains set up,
as it looks like the handover will be starting soon.

Sure, is it ok if I just attach the complete sources to this message?

Bas

Sure. Here's the merge, which duplicate what's in the JetBrains CVS now. It incorporates your fixes, some more of mine, one of (I assume) Maxim's. Also adds a handful of new inspections (boring stuff: portability checks for 1.5 constructs, and warnings about final methods or classes).

--Dave Griffith

Thanks. I have another change if there's still time: an improvement in the UI of the naming convention inspections. An error message popup when an incorrect regular expression is entered instead of infinite exceptions and the error reporting tool. The sources are attached.
By the way, there is something I don't understand in ImportUtils. There an inner class ClassReferenceVisitor is used, but I don't understand what it's supposed to do. As you may have noticed I removed the use of it in my sources, but I see you didn't incorporate that change.
With ClassReferenceVisitor in use the "Unnecessary fully qualified name" inspection doesn't work properly on the following code:

I'm confused.

Bas

I've merged your changes in. The ClassReferenceVisitor is there to see that references to things like java.awt.List don't get marked as unnecessary if there are any references to List and java.util.*|List is imported. That logic works, but unfortunately it gets confused in the java.lang special case. I'll fix it.

--Dave Griffith

The
ClassReferenceVisitor is there to see that references
to things like java.awt.List don't get marked as
unnecessary if there are any references to List and
java.util.*|List is imported.

I suspected something like that, but the methods 'hasExactImportConflict', 'hasOnDemandImportConflict' and 'containsConflictingClassReference' already solve that problem don't they? Your example works perfectly with the jar at the beginning of the thread and that doesn't use ClassReferenceVisitor.
Also I think that when ClassReferenceVisitor is in use any class that is referenced both fully qualified and with a short name like in my example, is not marked correctly.

Thanks for including my code,
Bas