Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 330734

Summary: Warn about field access outside getter and setter
Product: [Eclipse Project] JDT Reporter: Ed Willink <ed>
Component: CoreAssignee: JDT-Core-Inbox <jdt-core-inbox>
Status: VERIFIED WONTFIX QA Contact:
Severity: enhancement    
Priority: P3 CC: amj87.iitr, daniel_megert, markus.kell.r, Olivier_Thomann, satyam.kandula
Version: 3.7Keywords: needinfo
Target Milestone: 3.7 M4   
Hardware: All   
OS: All   
Whiteboard:

Description Ed Willink CLA 2010-11-20 08:59:28 EST 
It is common to provide a getXXX() API to make xxx accessible, but to bypass that API internally by direct access to xxx. A derived class can override getXXX() but fail to override as might be expected.

The above scenario could be diagnosed with a warning message, which disappears once the getXXX method is declared final thereby clarifying that the API is solely for read-access.
Comment 1 Dani Megert CLA 2010-11-22 03:27:31 EST 
"A derived class can override getXXX() but fail to override as might be expected."
Sorry, I don't understand that sentence. What should "override as expected" mean?
Comment 2 Ed Willink CLA 2010-11-22 03:40:35 EST 
A class such as

public class AmiguousGet
{
    private String name;

...

    public String getName() { return name; }

...
    private void doSomething() {
       .... = name ...
    }
}

appears to allow getName() be overridden by perhaps

    @Override
    public String getName() { return super.getName().toUpperCase(); }
 
but this override fails to affect the bypass usage in doSomething(), so the override does not work as might be expected.

I am suggesting that the use of name in doSomething() provoke a warning for which quick fixes could be 'make getName() final' or 'replace direct field access by getName()' or 'add @nooverride to getName()'.
Comment 3 Ayushman Jain CLA 2010-11-22 03:50:12 EST 
(In reply to comment #2)
>[..]

I don't think it is the compiler's business to oversee how a getter method is used. What if the user wanted the getName() method to get the field in a particular format, and at some place he just wants to get the field in the original format? We end up with an irritating, and not useful warning in such a case.

Also, this fails if I don't name my getter method as getXXX() and use some other naming convention, such as returnXXX()
Comment 4 Dani Megert CLA 2010-11-22 05:57:44 EST 
I agree with Ayush. There is no notion of getter/setter in the spec and JDT Core also has no knowledge about this except for suggesting the getter/setter names.
Comment 5 Ed Willink CLA 2010-11-22 06:27:28 EST 
This was triggered by Bug 329980.

I agree that an over-nannyish policing of get/set could be very irritating. On the other hand there is a reasonable requirement that the associated API be clear to the users, and checked on behalf of the developers.
Comment 6 Satyam Kandula CLA 2010-12-07 04:07:15 EST 
Verified for 3.7M4