[ANN] InspectionGadgets 0.0.3 released

Announcing the release of InspectionGadgets 0.0.3, for all your static analysis needs. Available at
http://www.intellij.org/twiki/bin/view/Main/InspectionGadgets, and requires Aurora build 896. If there are any problems, don't hesitate to let me hear 'em.

New Configuration Option
-


"InspectionGadgets error highlighting" toggle under the "Options" menu allows on-line error highlighting
to be quickly disabled. This is handy when looking at source code from others that has large numbers of errors
which you don't intend to fix.

New inspections
-


Unnecessary temporary object on conversion from basic type to String
Unnecessary temporary object on conversion from String to basic type
Object allocation in loop
Abstract method overrides abstract method
Instance variable not initialized by readObject
Class total cyclomatic complexity
Class inheritance depth
Class nesting depth
Class constructor count
Class field count
Class method count

New inspection options
-



"Local variable naming convention" inspection now has an option to ignore for-loop parameters.
"Local variable naming convention" inspection now has an option to ignore catch block parameters.
"Parameteter name hides instance variable" inspection now has an option to ignore parameters of setter methods.
"Parameteter name hides instance variable" inspection now has an option to ignore parameters of constructors.
"Local variable name hides instance variable" inspection now has an option to ignore variables not visible from the current scope.
"Parameteter name hides instance variable" inspection now has an option to ignore variables not visible from the current scope.
"Field names hides superclass field" inspection now has an option to ignore variables not visible from the current scope.

Inspection removed
-


The inspection for if/for/while/do-while statements whose body is not wrapped in {} has been removed,
now that IDEA has (finally) been extended to do this automatically via "Reformat Code".

Bug fixes
-


"Hardcoded File Separators" now ignores common date format strings (thanks to Vilya Harvey for this code).
Fixed bug where the "Parameter Naming Convention" and "Parameter hides instance variable" inspections
check catch block parameters, instead of just method parameters
Fixed bug where the "Local Variable Naming Convention" and "Local variable hides instance variable" inspections
do not check catch block parameters
Inspections dealing with collections classes now work with the com.sun.java.lang.util collection classes.
Fixed bug in "overridable method call in constructor" that incorrectly flagged constructor calls to "this" and "super".
"String literal as argument to .equals()" now works on .equalsIgnoreCase() as well.
"Abstract method overrides concrete method" fixed to work correctly with interfaces

34 comments
Comment actions Permalink

Thanks for the update. Unfortunately, I'm still seeing warnings for local
variables with the same name as package-private fields in superclasses in a
different package, even though the new option is selected. :(

Dave Griffith wrote:

"Local variable name hides instance
variable" inspection now has an option to ignore variables not
visible from the current scope.



0
Comment actions Permalink

Bug: InspectionGadgets wants to convert "new
Double(string).doubleValue()" to "Double.valueOf(string)", but the first
expression returns a primitive double while valueOf returns a Double
object. Maybe you meant Double.parseDouble(string)?


0
Comment actions Permalink


Serves me right for not doing a full test on that feature. A new version (still marked 0.0.3) has been uploaded to the Wiki with this bug fixed.

0
Comment actions Permalink


Doh!!!

A new version (still marked 0.0.3) has been uploaded to the Wiki, which fixes this bug.

--Dave "This may be the stupidest bug I've ever coded" Griffith

0
Comment actions Permalink

Cheers!

By the way, sometimes I get this when I try to remove a modifier using the
intention. Don't know if its your side or not, but I thought I'd let you
know.

ERROR - mand.impl.CommandProcessorImpl -
ERROR - mand.impl.CommandProcessorImpl -
ERROR - mand.impl.CommandProcessorImpl - IntelliJ IDEA (Aurora)
Bui
ld #896
ERROR - mand.impl.CommandProcessorImpl - IntelliJ IDEA (Aurora)
Bui
ld #896
ERROR - mand.impl.CommandProcessorImpl - JDK: 1.4.2
ERROR - mand.impl.CommandProcessorImpl - JDK: 1.4.2
ERROR - mand.impl.CommandProcessorImpl - VM: Java HotSpot(TM)
Client
VM
ERROR - mand.impl.CommandProcessorImpl - VM: Java HotSpot(TM)
Client
VM
ERROR - mand.impl.CommandProcessorImpl - Vendor: Sun Microsystems
Inc
.
ERROR - mand.impl.CommandProcessorImpl - Vendor: Sun Microsystems
Inc
.
ERROR - mand.impl.CommandProcessorImpl - OS: Windows XP
ERROR - mand.impl.CommandProcessorImpl - OS: Windows XP
ERROR - mand.impl.CommandProcessorImpl - Last Action:
ShowIntentionAc
tions
ERROR - mand.impl.CommandProcessorImpl - Last Action:
ShowIntentionAc
tions
ERROR - mand.impl.CommandProcessorImpl - Current Command: Remove
modi
fier
ERROR - mand.impl.CommandProcessorImpl - Current Command: Remove
modi
fier
ERROR - mand.impl.CommandProcessorImpl -
java.lang.NullPointerException
at com.intellij.psi.impl.source.b.h.b(h.java:27)
at com.intellij.psi.impl.source.b.h.a(h.java:199)
at com.intellij.psi.impl.source.e.r.b(r.java:112)
at com.intellij.psi.impl.source.e.bh.delete(bh.java:44)
at
com.siyeh.ig.verbose.UnnecessaryInterfaceModifierInspection$Unnecessa
ryInterfaceModifersFix.applyFix(UnnecessaryInterfaceModifierInspection.java:
77)
at com.intellij.codeInspection.u.bk.invoke(bk.java:9)
at com.intellij.codeInsight.intention.b.bm.run(bm.java:7)
at com.intellij.openapi.application.a.d.runWriteAction(d.java:262)
at com.intellij.codeInsight.intention.b.bl.run(bl.java)
at com.intellij.openapi.command.b.b.executeCommand(b.java:26)
at com.intellij.codeInsight.intention.b.bu.run(bu.java)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at com.intellij.ide.s.a(s.java:42)
at com.intellij.ide.s.dispatchEvent(s.java:104)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown
Source)

at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown
Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)

Dave Griffith wrote:

Serves me right for not doing a full test on that feature. A new
version (still marked 0.0.3) has been uploaded to the Wiki with this
bug fixed.




0
Comment actions Permalink

Very nice plugin - I like it ;)

0
Comment actions Permalink

Border case that happens some times:

Inspection warning: Assignment to for-loop parameter j

The declaration of the j variable could be moved outside the for, but this would unnecessarily expose the variable.

Could for control variables not changed in the update part not have this warning?

0
Comment actions Permalink

Inspection warning: Package-visible field whatever

Offer intention to make field private.

0
Comment actions Permalink

Doing this right would require calling the "Encapsulate Field" refactoring, to create getters and setters and change any other classes to use them instead of direct variable access. I've got an open tracker item that would allow me to do that, but at present the API just doesn't seem to allow it.

--Dave Griffith

0
Comment actions Permalink

Yes, and for added coolness, do this in a smart way - e.g. check if anything
is relying on the field being visible, if so, do encapsulate field as
suggested, otherwise just privatise.

N.

Dave Griffith wrote:

Doing this right would require calling the "Encapsulate Field"
refactoring, to create getters and setters and change any other
classes to use them instead of direct variable access. I've got an
open tracker item that would allow me to do that, but at present the
API just doesn't seem to allow it.

>

--Dave Griffith



0
Comment actions Permalink


But there's already a built-in inspection that will tighten up access if possible.

0
Comment actions Permalink

So is this available via InspectionGadgets then?

Dave Griffith wrote:

But there's already a built-in inspection that will tighten up access
if possible.



0
Comment actions Permalink

Doing this right would require calling the "Encapsulate Field"

refactoring,

I was only hoping/asking for a dumb "Add private modifier to field
declaration" intention. If code doesn't compile after this (which I don't
mind), undoing the change is easy and the field can be encapsulated.


"Nathan Brown" <nedski@yahoo.com> wrote in message
news:bii9f7$mfg$1@is.intellij.net...

So is this available via InspectionGadgets then?

>

Dave Griffith wrote:

But there's already a built-in inspection that will tighten up access
if possible.


Didn't find it in the ide options->errors panel. Maybe it's available only
in the inspection action?


0
Comment actions Permalink


That would be trivially easy, but I really don't like the idea of creating uncompilable code via quick-fixes. Let me think about it.

--Dave

0
Comment actions Permalink

That would be trivially easy, but I really don't like the

idea of creating uncompilable code via quick-fixes.

I don't much mind uncompilable code (I do very much mind changes that
compile but silently modify what the program does :-).

And in this case, the correction is going to the declaration and removing
the "private" modifier, so there's not much to undo .

Also, I haven't yet had a case where I was accessing a field directly. The
missing private modifier has crept in only in some inner classes accessed
mainly/only by the parent, so I haven't needed the encapsulate refactoring
:)

Let me think about it.


Adding the encapsulate refactoring if needed is the right thing to do, so
don't feel pressed to add this hack :) Writing "private" at the beginning
of the line is not too much work.

Carlos


0
Comment actions Permalink

I dont' understand why the following two array s are flagged as being octal and decimal.

Octal and decimal integers are in the same array initializer at line 110

private final static byte YY_ATTRIBUTE[] = {
1, 1, 1, 9, 1, 0, 0, 0, 1, 1, 1, 0, 9, 1
};


Octal and decimal integers are in the same array initializer at line 73

final private static int yy_rowMap [] = {
0, 4, 8, 12, 16, 8, 20, 24, 4, 28,
16, 32, 12, 24
};

0
Comment actions Permalink

Because I'm an idiot, and missed the special case of decimal arrays which contain "0". I'll put out a fix shortly.

--Dave Griffith

0
Comment actions Permalink

Some General Comments:

To get started with the inspections, I turned most of them on, and ran the inspection tool over the entire project. In the process of doing this I found the following things could be improved:

+ Inspection Tree
- The toplevel folders should be grouped together and the toplevel non-folders should be grouped together. [see inspection-groupedfolders.gif
- Within a Folder, the Inspections are not sorted by name.

+ Inspection Results Tree

- IMO the auto-scroll-to-source button should be on by default. I think most people what to see the editor display the source code when a results item is clicked.

- The auto-scroll-to-source just jumps to the 'Location' as listed in the detail pane; It doesn't jump to the first item under 'Problem Synopsis'

- The Results Tree should fully expand all locations to show all items instead of listing a location once with number of items (10 items). I shouldn't have to goto the detail pane to get to each problem. It should all be accessible from the results tree on the left-hand-side. The way it works now is non-intuitive. Imagine if it worked like this for compiler errors, e.g. on th left-hand-side it lists a method (7 errors), and then you have to click on it, then goto the right-hand-side to find each of the errors.

- One problem I had when I was experimenting is that I would find some of the inspections I wanted to turn off, but it took me awhile to track down the inspection in the Inspection Tool dialog. The following enhancements would be this easier to do:

- Somewhere in the results, the folder name should be displayed. That would make it much easier to find the inspections. The panel title, e..g 'Inspection - Assignment to method parameter' should say 'Inspection - Potentially confusing code constructs - Assigment to method parameter'

- Ideally, I would like a button in the Inspection Tool window 'Edit Inspection' which would popup the Inspection Tool Dialog and autoselect the current inspection, so I can either edit the parameters for the inspection or disable the inspection.

- The 'Apply an inspection quickfix' lightbulb icon is enabled even if no quickfix was available. If you click the icon, a popup menu just says 'Accept Resolution'. If you click it, it causes an IDEA Internal Error.

- I would prefer to do away with the tabs, and just make each tab a toplevel folder in the results tree.



Attachment(s):
inspection-groupfolders.gif
inspection-autosort.gif
inspection-toomany-tabs.gif
0
Comment actions Permalink

>To get started with the inspections, I turned most of >them on, and ran the inspection tool over the entire >project.

A tempting plan, but likely to overwhelm you.

I like a lot of your suggestions, and am unsure about others, but they are all things that have to be done by JetBrains, not me. Best to issue a whole bunch of Tracker items.

0
Comment actions Permalink

ok, will do

0
Comment actions Permalink

All of your notes do concern IDEA inspection API implementation rather than
InspectionGadgets plugin. Please do post them into tracker. Many of them
(like grouping suggestions) are more than discussable IMO though.

--

Best regards,
Maxim Shafirov
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"


"Alex" <no_mail@jetbrains.com> wrote in message
news:31515322.1062007484171.JavaMail.itn@is.intellij.net...

Some General Comments:

>

To get started with the inspections, I turned most of them on, and ran the

inspection tool over the entire project. In the process of doing this I
found the following things could be improved:
>

+ Inspection Tree
- The toplevel folders should be grouped together and the toplevel

non-folders should be grouped together. [see inspection-groupedfolders.gif

- Within a Folder, the Inspections are not sorted by name. [see

inspection-sorted.gif ]
>

+ Inspection Results Tree

>

- IMO the auto-scroll-to-source button should be on by default. I think

most people what to see the editor display the source code when a results
item is clicked.
>

- The auto-scroll-to-source just jumps to the 'Location' as listed in

the detail pane; It doesn't jump to the first item under 'Problem Synopsis'
>

- The Results Tree should fully expand all locations to show all items

instead of listing a location once with number of items (10 items). I
shouldn't have to goto the detail pane to get to each problem. It should all
be accessible from the results tree on the left-hand-side. The way it
works now is non-intuitive. Imagine if it worked like this for compiler
errors, e.g. on th left-hand-side it lists a method (7 errors), and then you
have to click on it, then goto the right-hand-side to find each of the
errors.
>

- One problem I had when I was experimenting is that I would find some

of the inspections I wanted to turn off, but it took me awhile to track down
the inspection in the Inspection Tool dialog. The following enhancements
would be this easier to do:
>

- Somewhere in the results, the folder name should be displayed. That

would make it much easier to find the inspections. The panel title, e..g
'Inspection - Assignment to method parameter' should say 'Inspection -
Potentially confusing code constructs - Assigment to method parameter'
>

- Ideally, I would like a button in the Inspection Tool window 'Edit

Inspection' which would popup the Inspection Tool Dialog and autoselect the
current inspection, so I can either edit the parameters for the inspection
or disable the inspection.
>

- The 'Apply an inspection quickfix' lightbulb icon is enabled even if

no quickfix was available. If you click the icon, a popup menu just says
'Accept Resolution'. If you click it, it causes an IDEA Internal Error.
>

- I would prefer to do away with the tabs, and just make each tab a

toplevel folder in the results tree.
>


0
Comment actions Permalink

All of your notes do concern IDEA inspection API
implementation rather than
InspectionGadgets plugin. Please do post them into
tracker. Many of them
(like grouping suggestions) are more than discussable
IMO though.


"Please do post them into tracker". Then you should probably make changes at http://www.intellij.org/twiki/bin/view/Main/InspectionPlugins ("API uses PSI(ProgramStructureInterface) and thus is "open" at the same terms.") or http://www.intellij.org/twiki/bin/view/Main/ProgramStructureInterface ("Please note that PSI is not a part of official openapi. So you shouldn’t: - Fill in SCRs about PSI – it’s totally unsupported by now.")?


Timur

0
Comment actions Permalink

No, because he's not suggesting changes to the OpenAPI. He's suggesting changes to the inspection panel.

0
Comment actions Permalink

My understanding is that it's not ok (at least according to web pages I mentioned) to file SCRs regarding suggested implementation changes of semi-open API.

0
Comment actions Permalink

"Then you should probably make changes ..."

I think the policy needs to be updated. People are posting questions regarding semi-open APIs to newsgroups anyway (it's just more convenient). JetBrains programmers ask for feedback, questions (and very promptly address them) for just released semi-open API (intention, inspection, testing framework).

I think there should be no restrictions on posting any questions at the newsgroups/forums (it's impossible to enforce any restrictions anyway). Also it should be ok to file any SCRs. The policy could be that it's not guaranteed that it will be addressed at all by JetBrains. See also http://www.intellij.net/tracker/idea/viewSCR?publicId=13355#507361 (I agree with Jacques).


Timur

0
Comment actions Permalink

Feature Requests:
#15459- Tools->Inspect Code->Inspections Panel should sort the inspections
#15461- Tools->Inspect Code, Inspections Results Tree enhancements.
#15463- Tools->Inspect Code, Inspections Results Window enhancements.

Bugs
#15464- Tools->Inspect Code, Inspections Results Window, IDEA Internal Error if no quickfix

0
Comment actions Permalink

All the problems (?) Alex had mentioned concerns IDEA's own inspections as
well as Dave's ones. In any case almost every functionality in IDEA is
implementation of PSI or its usage. Will this prevent you from submitting
feature requests against those functionalities?

--

Best regards,
Maxim Shafirov
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"


"Timur Zambalayev" <no_mail@jetbrains.com> wrote in message
news:2184024.1062016761774.JavaMail.itn@is.intellij.net...

My understanding is that it's not ok (at least according to web pages I

mentioned) to file SCRs regarding suggested implementation changes of
semi-open API.


0
Comment actions Permalink

java.lang.NullPointerException

at com.siyeh.ig.psiutils.ClassUtils.inSamePackage(ClassUtils.java:87)

at
com.siyeh.ig.visibility.LocalVariableHidingMemberVariableInspection$LocalVar
iableHidingMemberVariableVisitor.checkFieldName(LocalVariableHidingMemberVar
iableInspection.java:156)

at
com.siyeh.ig.visibility.LocalVariableHidingMemberVariableInspection$LocalVar
iableHidingMemberVariableVisitor.visitLocalVariable(LocalVariableHidingMembe
rVariableInspection.java:96)

at
com.intellij.psi.impl.source.tree.java.PsiLocalVariableImpl.accept(PsiLocalV
ariableImpl.java:207)

at
com.intellij.psi.impl.source.tree.CompositePsiElement.acceptChildren(Composi
tePsiElement.java:35)

at
com.intellij.psi.PsiRecursiveElementVisitor.visitElement(PsiRecursiveElement
Visitor.java:7)

at
com.intellij.psi.JavaElementVisitor.visitStatement(JavaElementVisitor.java:2
49)

at
com.intellij.psi.JavaElementVisitor.visitDeclarationStatement(JavaElementVis
itor.java:75)

at
com.intellij.psi.impl.source.tree.java.PsiDeclarationStatementImpl.accept(Ps
iDeclarationStatementImpl.java:31)

at
com.intellij.psi.impl.source.tree.CompositePsiElement.acceptChildren(Composi
tePsiElement.java:35)

at
com.intellij.psi.PsiRecursiveElementVisitor.visitElement(PsiRecursiveElement
Visitor.java:7)

at
com.intellij.psi.JavaElementVisitor.visitCodeBlock(JavaElementVisitor.java:5
9)

at
com.intellij.psi.impl.source.tree.java.PsiCodeBlockImpl.accept(PsiCodeBlockI
mpl.java:78)

at
com.intellij.psi.impl.source.tree.CompositePsiElement.acceptChildren(Composi
tePsiElement.java:35)

at
com.intellij.psi.PsiRecursiveElementVisitor.visitElement(PsiRecursiveElement
Visitor.java:7)

at
com.intellij.psi.JavaElementVisitor.visitStatement(JavaElementVisitor.java:2
49)

at
com.intellij.psi.JavaElementVisitor.visitBlockStatement(JavaElementVisitor.j
ava:39)

at
com.intellij.psi.impl.source.tree.java.PsiBlockStatementImpl.accept(PsiBlock
StatementImpl.java:39)

at
com.intellij.psi.impl.source.tree.CompositePsiElement.acceptChildren(Composi
tePsiElement.java:35)

at
com.intellij.psi.PsiRecursiveElementVisitor.visitElement(PsiRecursiveElement
Visitor.java:7)

at
com.intellij.psi.JavaElementVisitor.visitStatement(JavaElementVisitor.java:2
49)

at
com.intellij.psi.JavaElementVisitor.visitForStatement(JavaElementVisitor.jav
a:127)

at
com.intellij.psi.impl.source.tree.java.PsiForStatementImpl.accept(PsiForStat
ementImpl.java:120)

at
com.intellij.psi.impl.source.tree.CompositePsiElement.acceptChildren(Composi
tePsiElement.java:35)

at
com.intellij.psi.PsiRecursiveElementVisitor.visitElement(PsiRecursiveElement
Visitor.java:7)

at
com.intellij.psi.JavaElementVisitor.visitCodeBlock(JavaElementVisitor.java:5
9)

at
com.intellij.psi.impl.source.tree.java.PsiCodeBlockImpl.accept(PsiCodeBlockI
mpl.java:78)

at
com.intellij.psi.impl.source.TreeWrapperPsiElement.acceptChildren(TreeWrappe
rPsiElement.java:63)

at
com.intellij.psi.PsiRecursiveElementVisitor.visitElement(PsiRecursiveElement
Visitor.java:7)

at
com.intellij.psi.JavaElementVisitor.visitMethod(JavaElementVisitor.java:175)

at
com.intellij.psi.impl.source.PsiMethodImpl.accept(PsiMethodImpl.java:255)

at com.siyeh.ig.MethodInspection.checkMethod(MethodInspection.java:27)

at
com.intellij.codeInsight.daemon.impl.LocalInspectionsPass.collectInformation
(LocalInspectionsPass.java:78)

at
com.intellij.codeInsight.daemon.impl.UpdateThread$2.run(UpdateThread.java:13
7)

at
com.intellij.openapi.application.impl.ApplicationImpl.runReadAction(Applicat
ionImpl.java:343)

at
com.intellij.codeInsight.daemon.impl.UpdateThread.doRun(UpdateThread.java:12
9)

at
com.intellij.codeInsight.daemon.impl.UpdateThread.access$100(UpdateThread.ja
va:15)

at
com.intellij.codeInsight.daemon.impl.UpdateThread$1.run(UpdateThread.java:11
5)

at
com.intellij.progress.ProgressManager.runProcess(ProgressManager.java:110)

at
com.intellij.codeInsight.daemon.impl.UpdateThread.run(UpdateThread.java:111)



--

Best regards,
Maxim Shafirov
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"


"Dave Griffith" <dave.griffith@cnn.com> wrote in message
news:17038588.1061822154221.JavaMail.itn@is.intellij.net...

Announcing the release of InspectionGadgets 0.0.3, for all your static

analysis needs. Available at

http://www.intellij.org/twiki/bin/view/Main/InspectionGadgets, and

requires Aurora build 896. If there are any problems, don't hesitate to let
me hear 'em.
>

New Configuration Option
------------------------
"InspectionGadgets error highlighting" toggle under the "Options" menu

allows on-line error highlighting

to be quickly disabled. This is handy when looking at source code from

others that has large numbers of errors

which you don't intend to fix.

>

New inspections
---------------
Unnecessary temporary object on conversion from basic type to String
Unnecessary temporary object on conversion from String to basic type
Object allocation in loop
Abstract method overrides abstract method
Instance variable not initialized by readObject
Class total cyclomatic complexity
Class inheritance depth
Class nesting depth
Class constructor count
Class field count
Class method count

>

New inspection options
----------------------

>

"Local variable naming convention" inspection now has an option to ignore

for-loop parameters.

"Local variable naming convention" inspection now has an option to ignore

catch block parameters.

"Parameteter name hides instance variable" inspection now has an option to

ignore parameters of setter methods.

"Parameteter name hides instance variable" inspection now has an option to

ignore parameters of constructors.

"Local variable name hides instance variable" inspection now has an option

to ignore variables not visible from the current scope.

"Parameteter name hides instance variable" inspection now has an option to

ignore variables not visible from the current scope.

"Field names hides superclass field" inspection now has an option to

ignore variables not visible from the current scope.
>

Inspection removed
------------------
The inspection for if/for/while/do-while statements whose body is not

wrapped in {} has been removed,

now that IDEA has (finally) been extended to do this automatically via

"Reformat Code".
>

Bug fixes
---------
"Hardcoded File Separators" now ignores common date format strings (thanks

to Vilya Harvey for this code).

Fixed bug where the "Parameter Naming Convention" and "Parameter hides

instance variable" inspections

check catch block parameters, instead of just method parameters
Fixed bug where the "Local Variable Naming Convention" and "Local variable

hides instance variable" inspections

do not check catch block parameters
Inspections dealing with collections classes now work with the

com.sun.java.lang.util collection classes.

Fixed bug in "overridable method call in constructor" that incorrectly

flagged constructor calls to "this" and "super".

"String literal as argument to .equals()" now works on .equalsIgnoreCase()

as well.

"Abstract method overrides concrete method" fixed to work correctly with

interfaces
>


0
Comment actions Permalink

All the problems (?) Alex had mentioned concerns
IDEA's own inspections as
well as Dave's ones. In any case almost every
functionality in IDEA is
implementation of PSI or its usage. Will this prevent
you from submitting
feature requests against those functionalities?


My understanding was that the spirit of the policy was: don't file SCRs regarding issues caused by plugins using semi-open API. So if I can repro/have the issue without any plugins using semi-open API, I can certainly file the issue. If it's caused/exposed by a plugin using semi-open API, I cannot (at least that was my understanding of the policy).


Timur

0
Comment actions Permalink

I guess, based on this read, that you might have a point. The "problem" these items are trying to address is that the Inspections GUI (not the API) doesn't beautifully scale to handle 180 different inspection types, although it handles the 15 or so built-in inspections well enough. Is this then an issue "caused" by the plugin, or an pre-existing issue "exposed" by the plugin? I'd vote the latter, and say that those fit the policy, but could see the argument. Apologies if my suggestions broke policy. I try never to do that by accident (preferring to save up karma for when I have to do it on purpose).

--Dave Griffith

0

Please sign in to leave a comment.