Where can I post bugs? Dangerous Intention: Field can be converted to variables.

Jan Moennich wrote:

Hi,

can we post bugs of intellij?

http://jetbrains.net/jira is the place

 public class Test {
>   
>   private boolean notified; // This cannot be converted!!!
>   synchronized void a() {
>     notified=false;
>     try {
>       wait();
>     } catch(InterruptedException e) {
>     }
>     if (notified) System.out.println("Notified!");
>   }
>   
>   synchronized void b() {
>     notified=true;
>     notify();
>   }
> }
> ]]>

It looks like in this example, the field is useless - it is never read.

I though I had already posted this one, but can't seem to find it. Just a documentation issue, IMHO. The fact that this inspection is non-thread-safe needs to be pointed out in the inspection description.

--Dave Griffith

Maybe the method wait() should be marked as a method who change anything...

I had another not-thread-related false-alarm with that intention yesterday
(build 3536), but was to lazy to report. I'll see, whether I find the class
again.

Tom

It's not about thread safeness. This intention seems to cache the document structure for longer then necessary. It usually works like this:

1) I use an unknown reference in a method body;
2) I choose the "create field" intention for the reference;
3) The field is created; "Field can be converted to local variable" inspection is triggered (correctly) at this point;
4) I generate the getter/setter pair for the field. The "Field can be converted..." intention does NOT go away

When this happens, I just insert and then remove a space in the field name; this seems to force the inspection to reevaluate the condition and go away.

This is probably the generic inspection update problem described in
http://www.jetbrains.net/jira/browse/IDEA-5399

Comment from Maxim Shafirov in
http://www.intellij.net/forums/thread.jsp?forum=22&thread=171613&message=4947660

"IDEA-5399 - known problem. Fix will require public API to change, which we
can't afford in bugfix update."


Marcus Brito wrote:

It's not about thread safeness. This intention seems to cache the document structure for longer then necessary. It usually works like this:

1) I use an unknown reference in a method body;
2) I choose the "create field" intention for the reference;
3) The field is created; "Field can be converted to local variable" inspection is triggered (correctly) at this point;
4) I generate the getter/setter pair for the field. The "Field can be converted..." intention does NOT go away

When this happens, I just insert and then remove a space in the field name; this seems to force the inspection to reevaluate the condition and go away.

It is indeed that bug. The basic problem is that inspections that require accessing information throughout a class do not get updated when a change is made inside an individual method. Other inspections that get this are things like "Mismatched update and query of collection" and "Field accessed in both synchronized and unsynchronized context". You can trigger a recalculation of such inspections with a code reformat (Ctrl-Alt-L), but that's only a workaround.

http://www.jetbrains.net/jira/browse/IDEA-5399 is probably the last serious weakness of the current inspection system, other than the lack of an OpenAPI for global inspections. Unfortunately, they would both require some fairly deep changes to the inspection life-cycle to fix. We can always hope for Demetra.

--Dave Griffith

Dave Griffith wrote:

You can trigger a recalculation of such
inspections with a code reformat (Ctrl-Alt-L), but that's only a
workaround.

Another way of triggering a recalculation is Save All (Ctrl+S). But
sometimes I wonder if that is desired behavior or a bug...

Bas

I've also ran into that inspection a couple of times and it gets really confusing. What makes it even more critical is that the inspection is enabled by default.

Would there be a way of removing the results of those inspections as soon as the file has changed, and have IDEA add the results again as soon as it notices that the class structure has changed? I think it would be better not to show anything than to show wrong information.