Bug 295819 - Changing constant value does not cause recompilation of code that uses it
Summary: Changing constant value does not cause recompilation of code that uses it
Status: NEW
Alias: None
Product: AspectJ
Classification: Tools
Component: Compiler (show other bugs)
Version: DEVELOPMENT   Edit
Hardware: PC Linux
: P2 major (vote)
Target Milestone: ---   Edit
Assignee: aspectj inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-11-22 20:50 EST by Guillaume Pothier CLA
Modified: 2013-06-24 11:04 EDT (History)
2 users (show)

See Also:


Attachments
Zipped workspace exhibiting the bug (7.45 MB, application/zip)
2009-11-23 13:20 EST, Guillaume Pothier CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Guillaume Pothier CLA 2009-11-22 20:50:30 EST
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4) Gecko/20091028 Ubuntu/9.10 (karmic) Firefox/3.5.4
Build Identifier: I20090611-1540

I have a class that declares a "public static final int" constant.
I have another class that uses this constant in a method, eg:
int stuff = MyClass.MY_CONST*8;

Let's say MY_CONST is 1. The first time I execute the above code after writing it (which means it HAS to be compiled at that point), the stuff variable will have the correct value (8). Now if I change the constant, let's say to 2, and execute the program again, the stuff variable still gets the previous value.
If I force full recompilation with a Clean and execute again, then the variable gets the correct value.
Note that this is not a new problem, I have also observed it with previous versions of Eclipse.
In my project, this problem is 100% reproducible. However, I created a test project with just two classes (one that defines the constant, another one that uses it, and the problem does not occur). Please tell me if I should upload my project somewhere so that the bug can be tracked down.

Reproducible: Always

Steps to Reproduce:
1. Change the value of a constant
2. Save the file 
3. Execute the program
Comment 1 Olivier Thomann CLA 2009-11-23 11:37:02 EST
(In reply to comment #0)
> In my project, this problem is 100% reproducible. However, I created a test
> project with just two classes (one that defines the constant, another one that
> uses it, and the problem does not occur). Please tell me if I should upload my
> project somewhere so that the bug can be tracked down.
Could you please attach your project to this bug report?
Thanks.
Comment 2 Guillaume Pothier CLA 2009-11-23 13:20:42 EST
Created attachment 152883 [details]
Zipped workspace exhibiting the bug

Note that the workspace is full of errors because I did not include the dependencies, but it doesn't prevent the bug from manifesting.

Steps to reproduce:
1. Execute tod.impl.evdbng.db.file.TestMinMaxTree (in src/test) as a Java application (*not* as a JUnit test)
2. Observe printed value.
3. Change the value of the PagedFile.PAGE_SIZE constant.
4. Execute the program again.
5. The printed value remains the same.
Comment 3 Olivier Thomann CLA 2009-11-24 13:35:35 EST
You are using aspectJ. Is that properly installed ?
Comment 4 Olivier Thomann CLA 2009-11-24 13:36:06 EST
What version of AspectJ are you using ?
Do you get the same behavior using a pure java project ?
Comment 5 Guillaume Pothier CLA 2009-11-24 13:59:19 EST
AspectJ problem indeed, converting the same project to a Java-only project makes the problem disappear.
I changed the Product to AJDT then.

I just tested again with a freshly installed Eclipse 3.5.1, and freshly installed AJDT from http://download.eclipse.org/tools/ajdt/35/update
The problem occurs whether or not the Incremental Compiler Optimizations option is checked.
Comment 6 Guillaume Pothier CLA 2009-11-24 14:06:45 EST
Actually, reproducing the bug is much simpler now that we know it is an AJDT
problem:

1. Create a new AJDT project
2. Create a class named Def:
public class Def {
    public static final int D = 3;
}

3. Create a class named Use:
public class Use {
    public static void main(String[] args) {
        System.out.println(Def.D);
    }
}

4. Execute class Use, observe output
5. Change the value of Def.D
6. Execute Use again, output does not change

I guess the big attachment can be deleted now, if possible; I don't know how to
do it myself.
Comment 7 Andrew Clement CLA 2009-11-24 14:15:05 EST
Looks AspectJ rather than AJDT.  Wonder which part of incremental compilation is to blame...  Could be AspectJ itself or it could be us missing a fix from Eclipse JDT since AspectJ is based on eclipse compiler level 785 (from Eclipse 3.3)
Comment 8 Andrew Clement CLA 2013-06-24 11:04:39 EDT
unsetting the target field which is currently set for something already released