[ANN] InspectionGadgets version 0.0.9 released.


Announcing version 0.0.9 of the InspectionGadgets plugin, available via the PluginManager or at http://www.intellij.org/twiki/bin/view/Main/InspectionGadgets.

Changes in version 0.0.9

Toggle for error highlighting now has a default key-binding: Alt-I
Inspection descriptions are now marked as "Powered by InspectionGadgets", for ease of error reporting

New Inspections

  • Cloneable class without 'clone()'

  • clone() doesn't declare CloneNotSupportedException

  • clone() instantiates objects with constructor

  • clone() doesn't call super.clone()

  • Confusing floating-point literal

  • Overly complex boolean expression

  • Overly complex arithmetic expression

  • No-op method in abstract class

  • Cloneable class in secure context

  • Serializeable class in secure context

  • Deserializeable class in secure context

  • Non-final field referenced in 'hashCode()'

  • Non-final field referenced in 'equals()'

  • Non-final field referenced in 'compareTo()'

  • Field accessed in both synchronized and unsynchronized contexts

  • Non-private field accessed in synchronized context

  • Implicit call to super()

  • Switch statement with too few branches

  • Synchronization on 'this'

  • Unnecessary code block

  • Concrete class for instance variable

  • Concrete class for static variable

  • Concrete class for method parameter

  • Concrete class for method return

  • Concrete class for local variable

  • Cast to a concrete class


plus a handful of bugfixes, refactorings, new configuration options, and general improvements

--Dave Griffith

23 comments
Comment actions Permalink

thanks ;)
an error though when using it to replace full qualified name with an import:


java.lang.NullPointerException

at com.intellij.psi.impl.q.createImportStatement(q.java:21)

at com.siyeh.ig.verbose.UnnecessaryFullyQualifiedNameInspection.addImportIfNecessary(UnnecessaryFullyQualifiedNameInspection.java:157)

at com.siyeh.ig.verbose.UnnecessaryFullyQualifiedNameInspection.access$200(UnnecessaryFullyQualifiedNameInspection.java:15)

at com.siyeh.ig.verbose.UnnecessaryFullyQualifiedNameInspection$UnnecessaryFullyQualifiedNameFix.applyFix(UnnecessaryFullyQualifiedNameInspection.java:71)

at com.intellij.codeInspection.i.n.invoke(n.java:5)

at com.intellij.codeInsight.intention.b.x$8.run(x$8.java:6)

at com.intellij.openapi.application.a.b.runWriteAction(b.java:289)

at com.intellij.codeInsight.intention.b.x$11.run(x$11.java:1)

at com.intellij.openapi.command.impl.a.executeCommand(a.java:43)

at com.intellij.codeInsight.intention.b.x$0.run(x$0.java:9)

at com.intellij.util.LaterInvocator$FlushQueue.run(LaterInvocator.java:0)

at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178)

at java.awt.EventQueue.dispatchEvent(EventQueue.java:454)

at com.intellij.ide.q.b(q.java:95)

at com.intellij.ide.q.a(q.java:124)

at com.intellij.ide.q.dispatchEvent(q.java:67)

at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:201)

at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:151)

at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145)

at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137)

at java.awt.EventDispatchThread.run(EventDispatchThread.java:100)

0
Comment actions Permalink

I LOVE this plugin!

One question, though. I've noticed that as I upgrade my versions of
Aurora, I keep having to reset certain of the real-time error checking
parameters (I don't like member variables with a leading "m_", for
instance). I'm guessing this is a function of Idea rather than your
plugin.

Would there be a way, perhaps to export settings and then re-import
them?

On a related note, at my company we're trying to standardize coding
conventions, and we'd love to use this plugin as a start. How about the
ability to point the plugin at a URL or configurable file location for
the configuration? That way all the developers can check their work
against a common set of standards which can be centrally managed.

Thanks once again!

Douglas Bullard


In article <29981079.1073840572029.JavaMail.itn@is.intellij.net>,
dave.griffith@cnn.com says...


Announcing version 0.0.9 of the InspectionGadgets plugin, available via the PluginManager or at http://www.intellij.org/twiki/bin/view/Main/InspectionGadgets.

Changes in version 0.0.9

Toggle for error highlighting now has a default key-binding: Alt-I
Inspection descriptions are now marked as "Powered by InspectionGadgets", for ease of error reporting

New Inspections

  • Cloneable class without 'clone()'

  • clone() doesn't declare CloneNotSupportedException

  • clone() instantiates objects with constructor

  • clone() doesn't call super.clone()

  • Confusing floating-point literal

  • Overly complex boolean expression

  • Overly complex arithmetic expression

  • No-op method in abstract class

  • Cloneable class in secure context

  • Serializeable class in secure context

  • Deserializeable class in secure context

  • Non-final field referenced in 'hashCode()'

  • Non-final field referenced in 'equals()'

  • Non-final field referenced in 'compareTo()'

  • Field accessed in both synchronized and unsynchronized contexts

  • Non-private field accessed in synchronized context

  • Implicit call to super()

  • Switch statement with too few branches

  • Synchronization on 'this'

  • Unnecessary code block

  • Concrete class for instance variable

  • Concrete class for static variable

  • Concrete class for method parameter

  • Concrete class for method return

  • Concrete class for local variable

  • Cast to a concrete class


plus a handful of bugfixes, refactorings, new configuration options, and general improvements

--Dave Griffith

0
Comment actions Permalink

I LOVE this plugin!

Thank you. I've had a lot of fun doing it, and it's not more than 2/3 done yet.

+One question, though. I've noticed that as I upgrade my versions of Aurora, I keep having to reset certain of the real-time error checking parameters (I don't like member variables with a leading "m_", for instance). I'm guessing this is a function of Idea rather than your
plugin. +

As far as I know, this has to do with IDEA, rather than the plugin. I personally don't see this (probably because I always install my settings in the same place).

Would there be a way, perhaps to export settings and then re-import them?

An excellent feature request, but it has to go to JetBrains, rather than me. Please submit a tracker request.

How about the ability to point the plugin at a URL or configurable file location for the configuration?

And another one. Please submit a tracker request.

--Dave "More work for you, Maxim" Griffith

0
Comment actions Permalink

Douglas Bullard wrote:

Would there be a way, perhaps to export settings and then re-import
them?

On a related note, at my company we're trying to standardize coding
conventions, and we'd love to use this plugin as a start. How about the
ability to point the plugin at a URL or configurable file location for
the configuration? That way all the developers can check their work
against a common set of standards which can be centrally managed.


You can set up and save different profiles for running inspections. They get
saved as XML files inside your settings directory. There is an open feature
request to have the real-time error checking use these profiles as well (I
forget the SCR number, but vote for it if you find it). I think that would
handle the majority of what you want.

You can also have a look at the editor.codeinsight.xml file inside your
settings directory. The contains the settings for the real-time error
checking. Look for something like this:

... which inspections to display as errors/warnings in the editor settings specific to each inspection ]]>

You could try copying and pasting this to ensure consistency between
developers. You could try splitting it out into a separate file & declaring
it as an external entity, but I suspect that would either break IDEA or be
lost as soon as your editor settings are saved again.

Hope that helps,
Vil.
--
Vilya Harvey
vilya.harvey@digitalsteps.com / digital steps /
(W) +44 (0)1483 469 480
(M) +44 (0)7816 678 457 http://www.digitalsteps.com/

0
Comment actions Permalink

It seems to that the new version is only available through the pluginmanager. On the wiki page I found only 0.0.8.

0
Comment actions Permalink


Hurm. Must have screwed up the editing there. I'll fix it by this evening.

--Dave

0
Comment actions Permalink

In article <btu8pc$e3m$1@is.intellij.net>, vilya.harvey@digitalsteps.com
says...

Douglas Bullard wrote:

Would there be a way, perhaps to export settings and then re-import
them?

On a related note, at my company we're trying to standardize coding
conventions, and we'd love to use this plugin as a start. How about the
ability to point the plugin at a URL or configurable file location for
the configuration? That way all the developers can check their work
against a common set of standards which can be centrally managed.


You can set up and save different profiles for running inspections. They get
saved as XML files inside your settings directory. There is an open feature
request to have the real-time error checking use these profiles as well (I
forget the SCR number, but vote for it if you find it). I think that would
handle the majority of what you want.

Exactly - I'd LOVE to be able to load/save error profiles in the same
way the inspections can.

You can also have a look at the editor.codeinsight.xml file inside your
settings directory. The contains the settings for the real-time error
checking. Look for something like this:

<component name="DaemonCodeAnalyzerSettings">
...
<option name="DISPLAY_LEVEL_MAP">
<value>
which inspections to display as errors/warnings in the editor
</value>
</option>
settings specific to each inspection
</component>

You could try copying and pasting this to ensure consistency between
developers. You could try splitting it out into a separate file & declaring
it as an external entity, but I suspect that would either break IDEA or be
lost as soon as your editor settings are saved again.

Yes, that's probably what we'll do, until a change to the API is made.
The problem is that it allows the developers to change the settings, and
we'd like to be a little more restrictive. Otherwise, they WILL change
the settings and then we'll catch it in a code review.

Thanks for the suggestions.


Doug

0
Comment actions Permalink

On Mon, 12 Jan 2004 21:49:09 -0800, Douglas Bullard wrote:

Yes, that's probably what we'll do, until a change to the API is made. The
problem is that it allows the developers to change the settings, and we'd
like to be a little more restrictive. Otherwise, they WILL change the
settings and then we'll catch it in a code review.


How long does it take to run an inspection on one individual file? I was
thinking an AutoInspection on a file each time its opened would be kinda
neat.

Note - only the first time its opened in a session. If you close the file
and reopen it don't rerun the inspection ( unless the time is minimal ).

This autoInspection could a option somewhere...

Thoughts? Maybe this option should go in its own plugin thou...

Mark

0
Comment actions Permalink

Thanks again for all your great work.

Here's an exception I get with build 1094 when correcting a "Field
initialization is redundant" in a static inner class:

Error message: Assertion failed
java.lang.Throwable
at com.intellij.openapi.diagnostic.Logger.assertTrue(Logger.java:66)
at com.intellij.openapi.diagnostic.Logger.assertTrue(Logger.java:37)
at com.intellij.psi.impl.source.g.bu.delete(bu.java:6)
at
com.siyeh.ig.verbose.RedundantFieldInitializationInspection$RedundantFieldInitializationFix.applyFix(RedundantFieldInitializationInspection.java:91)
at com.intellij.codeInspection.s.n.invoke(n.java:7)
at com.intellij.codeInsight.intention.b.y$8.run(y$8.java:6)
at com.intellij.openapi.application.b.b.runWriteAction(b.java:367)
at com.intellij.codeInsight.intention.b.y$11.run(y$11.java:2)
at com.intellij.openapi.command.impl.a.executeCommand(a.java:86)
at com.intellij.codeInsight.intention.b.y$0.run(y$0.java:0)
at com.intellij.util.LaterInvocator$FlushQueue.run(LaterInvocator.java:3)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:454)
at com.intellij.ide.q.b(q.java:94)
at com.intellij.ide.q.a(q.java:62)
at com.intellij.ide.q.dispatchEvent(q.java:68)
at
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:201)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:151)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:100)

0
Comment actions Permalink


This already exists. Just go to "Settings/Errors..." to turn on on-line error reporting. Third-party inspection errors will show up as "yellow-line" warnings, just like built-in errors. Quick-fixes will show up as intentions.

--Dave Griffith

0
Comment actions Permalink

Wierd, that worked before. I've got a fix, and will probably be putting out an 0.0.9.1 shortly.

0
Comment actions Permalink

I also get this exception. It happens are any field in any class for me.

class A {
public String fileName = null;
}

0
Comment actions Permalink

On Tue, 13 Jan 2004 12:41:13 +0000, Dave Griffith wrote:

This already exists. Just go to "Settings/Errors..." to turn on on-line
error reporting. Third-party inspection errors will show up as
"yellow-line" warnings, just like built-in errors. Quick-fixes will show
up as intentions.


Excellent :) Never spotted that before.

--
Discouragement is a dissatisfaction with the past, a distaste for the
present, and a distrust of the future - Maree De Jong, CLCA.

0
Comment actions Permalink

Do you plan to release the source code for version 0.0.9? I can't find
it on the wiki and I would like to make some small enhancements.

Bas

0
Comment actions Permalink

Had an inner (non-static) class that implemented an interface. The
interface was specified using a fully qualified name. Accepted the
intention to replace this with an import. I think IDEA was in the
process of analyzing the source file due to an earlier change I made.

java.lang.NullPointerException
at com.intellij.psi.impl.source.e.e.c(e.java:166)
at com.intellij.psi.impl.source.c.r.a(r.java:17)
at com.intellij.psi.impl.source.c.s.replace(s.java:59)
at
com.siyeh.ig.verbose.UnnecessaryFullyQualifiedNameInspection$UnnecessaryFullyQualifiedNameFix.applyFix(UnnecessaryFullyQualifiedNameInspection.java:70)
at com.intellij.codeInspection.n.n.invoke(n.java:4)
at com.intellij.codeInsight.intention.a.y$8.run(y$8.java:2)
at com.intellij.openapi.application.a.b.runWriteAction(b.java:5)
at com.intellij.codeInsight.intention.a.y$11.run(y$11.java:2)
at com.intellij.openapi.command.impl.a.executeCommand(a.java:109)
at com.intellij.codeInsight.intention.a.y$0.run(y$0.java:5)
at com.intellij.util.LaterInvocator$FlushQueue.run(LaterInvocator.java:5)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:454)
at com.intellij.ide.q.b(q.java:130)
at com.intellij.ide.q.a(q.java:53)
at com.intellij.ide.q.dispatchEvent(q.java:16)
at
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:201)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:151)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:100)

0
Comment actions Permalink

Jonas Kvarnström wrote:

java.lang.NullPointerException


Tried it again when IDEA had finished analyzing the file and got no NPE.

0
Comment actions Permalink

Yes, but I've been swamped. I'll try to get it on the wiki later today.

What are your enhancements, if you don't mind me asking. Anything that should go in the core product?

--Dave

0
Comment actions Permalink

On 2004/01/15 15:09, Dave Griffith wrote:

Yes, but I've been swamped. I'll try to get it on the wiki later
today.


Ok, I will keep an eye on it. Thanks.

What are your enhancements, if you don't mind me asking. Anything
that should go in the core product?


At this moment just two small things:
- I would like to mark/highlight all inspections that have a quick fix.
Probably simply the same way as on the wiki by placing an asterisk
behind the name.
- Give the "Empty 'catch' block" inspection an option to not check in
subclasses of junit.framework.TestCase

I'll leave it up to you if you think those things are worthwhile for
your release.

Bas


0
Comment actions Permalink


I like both of these, although I'm not sure of the UI design for the first one. I'll probably either do them, or if you want to do them first I'll merge them in.

--Dave

0
Comment actions Permalink


The version 0.0.9 source and jar are now up on the wiki

--Dave

0
Comment actions Permalink

The version 0.0.9 source and jar are now up on the wiki.

--Dave

0
Comment actions Permalink

I've found a strange problem with the "Unnecessary fully qualified name" inspection. Take the following code (with caret position shown by |):


Accept the "Replace with import" statement and we get:

import java.util.ArrayList;

public class Test {
public static void main(String[] args) {
ArrayList a = new ArrayList();
for (int i = 0; i<a.size(); i++) {
String s = (java.lang.String) a.get(i);
}
}
}

as expected. However... the line "String s = (java.lang.String) a.get(i);" is highlighted as an error - "Incompatible types. Found 'java.lang.String', required: 'java.lang.String[]'"

Pressing enter at the end of the line seems to clear the error. Weird!

0
Comment actions Permalink


A known issue, and one I've not managed to find a fix for. Sorry.

--Dave

0

Please sign in to leave a comment.