This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 240163 - Wrong hint suggest to add final modifier on a variable assigned multiple times
Summary: Wrong hint suggest to add final modifier on a variable assigned multiple times
Status: REOPENED
Alias: None
Product: java
Classification: Unclassified
Component: Hints (show other bugs)
Version: 8.0
Hardware: PC All
: P3 normal (vote)
Assignee: Svata Dedic
URL:
Keywords:
: 239248 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-01-09 14:44 UTC by unai
Modified: 2015-10-02 16:30 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description unai 2014-01-09 14:44:17 UTC
[ BUILD # : 201401090002 ]
[ JDK VERSION : 1.7.0_45 ]

STEPS:
public class JavaApplication1
{
    private short temper;//hint "Field temper can be final"
    public JavaApplication1()
    {
        temper = 1;
    }
    public JavaApplication1(short a)
    {
        this();
        temper = a;//If you apply the suggested hint above you get the warning
"variable temper might already have been assigned"
    }
}

ACTUAL:
    Hint leads to a worse situation.

EXPECTED:
   * Such hint should not appear. It should be detected that the second
constructor calls the first one, and both assign the [hintedly final] variable;
Comment 1 Jiri Prox 2014-01-09 15:32:52 UTC
This is the same as issue 237238. But the bug is still reproducible so I'll keep this opened (not marking as duplicate)


Product Version: NetBeans IDE Dev (Build 20140109-5dd3d83bf20e)
Java: 1.8.0-ea; Java HotSpot(TM) 64-Bit Server VM 25.0-b49
Runtime: Java(TM) SE Runtime Environment 1.8.0-ea-b107
System: Windows 7 version 6.1 running on amd64; Cp1250; en_US (nb)
User directory: C:\Users\jprox\AppData\Roaming\NetBeans\dev
Cache directory: C:\Users\jprox\AppData\Local\NetBeans\Cache\dev
Comment 2 swpalmer 2014-01-13 12:36:31 UTC
Reproducible on OS X with:

Product Version: NetBeans IDE 8.0 Beta (Build 201401091443)
Java: 1.8.0-ea; Java HotSpot(TM) 64-Bit Server VM 25.0-b63
Runtime: Java(TM) SE Runtime Environment 1.8.0-ea-b121
System: Mac OS X version 10.9.1 running on x86_64; UTF-8; en_US (nb)
Comment 3 Svata Dedic 2014-01-24 16:42:09 UTC
This is a slightly different case than issue #237238. The field is only assigned form constructors, not assigned from elsewhere. 

The hint is actually correct, although some manual work is needed with this particular example:
The 0-arg ctor has to call the 1-arg one, not the other way around. Automating the change may be difficult - ctor call must be the 1st statement, however code in 0-arg ctor may do different things before the field is assigned.

If I changed the hint to take constructor-based assignments into account, then NetBeans may miss a lot of cases where the field could be actually final after the object construction finishes.

I admit the behaviour is not optimal, but can't think of a relatively simple yet correct way to automate the constructor delegation.
Comment 4 Svata Dedic 2014-01-24 17:29:49 UTC
*** Bug 239248 has been marked as a duplicate of this bug. ***
Comment 5 unai 2014-02-04 13:45:11 UTC
Wouldn't it be better to miss some final hints (given that compiler might outsmart us in any case), rather than allowing buggy scenarios such as this one to occur?
Comment 6 Svata Dedic 2014-02-04 14:48:52 UTC
(In reply to unai from comment #5)
> Wouldn't it be better to miss some final hints (given that compiler might
> outsmart us in any case), rather than allowing buggy scenarios such as this
> one to occur?

Your compiler warns or suggest that a certain variable/field, which is currently NOT declared final COULD be declared as final ?
Comment 7 unai 2014-02-04 16:02:50 UTC
No, I didn't want to insinuate anything, it's just that I've grown to learn that, more often than not, compilers tend to outsmart higher level microoptimizations, inferring that if making a variable final could improve the program's execution, the bytecode compiler (or the JIT compiler) would detect that and take care of it. And the fact that, to my eyes, having a hint that when applied leads your code to a new error condition looks worse than not having such hint in the first place.
Not a big deal though, I can always disable it from the Options window.
Cheers
Comment 8 Svata Dedic 2014-02-04 16:30:28 UTC
(In reply to unai from comment #7)
> Not a big deal though, I can always disable it from the Options window.
> Cheers

Hm, still I'll try to make some adjustment. Although it's not straightforward to restructure the code automatically, I can still make the hint to appear, but only offer a fix only for the simple cases.
+ possibly make the hint configurable so that if more ctors initialize the variable, the hint will be suppressed.

OK ?
Comment 9 unai 2014-02-05 09:18:08 UTC
That would be awesome!
Comment 10 Svata Dedic 2014-02-18 18:01:52 UTC
sorry, past UI freeze. I'll try to add the option later, however the optional appearance of the fix can go to 8.0.

Keeping as enhancement until option is implemented.

Fix appearance modified in jet-main#f18dcdcc0c16
Comment 11 Quality Engineering 2014-02-20 03:03:38 UTC
Integrated into 'main-silver', will be available in build *201402200001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/f18dcdcc0c16
User: Svata Dedic <sdedic@netbeans.org>
Log: #240163: do not offer fix for fields initialized in multiple constructors