Bug 80964 - [1.5] Annotations with RetentionPolicy.RUNTIME are lost after a rebuild
Summary: [1.5] Annotations with RetentionPolicy.RUNTIME are lost after a rebuild
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows XP
: P3 major (vote)
Target Milestone: 3.1 M4   Edit
Assignee: Philipe Mulet CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-12-14 13:22 EST by Stefan Zeiger CLA
Modified: 2004-12-15 20:52 EST (History)
0 users

See Also:


Attachments
Two classes which demonstrate the problem. (656 bytes, application/zip)
2004-12-14 13:23 EST, Stefan Zeiger CLA
no flags Details
Apply on org.eclipse.jdt.core.tests.compiler in HEAD (2.92 KB, patch)
2004-12-14 17:32 EST, Olivier Thomann CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Zeiger CLA 2004-12-14 13:22:14 EST
After doing a full rebuild (Project -> Clean) on a project containing an
annotation and a class where the annotation is used, the annotation is not
available at runtime. Doing a change to the class where it is used and saving
the class to force a recompile makes the annotation visible again.

Tested with I20041207 and I20041214.
Comment 1 Stefan Zeiger CLA 2004-12-14 13:23:37 EST
Created attachment 16589 [details]
Two classes which demonstrate the problem.

Here are an annotation class and a main class which uses the annotation and
checks for its existence at runtime.
Comment 2 Jerome Lanneluc CLA 2004-12-14 15:49:21 EST
Kent, can you please investigate ? (it looks like a full build produces a
different class file then an incremental build)
Comment 3 Philipe Mulet CLA 2004-12-14 15:54:42 EST
Issue is likely in Olivier's hands where the classfile is misgenerated, and thus
misbehaving when compiled agasint, as opposed to when compiled against sources
directly (fullbuild case).
Comment 4 Olivier Thomann CLA 2004-12-14 15:59:48 EST
I will investigate.
Comment 5 Olivier Thomann CLA 2004-12-14 16:50:40 EST
The problem comes from the fact that in full build, the method setFoo is
generated before the tagBits for Ann are set. Therefore it is too late to find
out that the retention is RUNTIME.
Comment 6 Olivier Thomann CLA 2004-12-14 17:02:30 EST
When Main is compiled against the binary type Ann, then it works fine, because
the tagBits for a binary type are set when the classfile reader initializes the
structure of Ann.
If the two types are defined in the same CU, then it also works because all
types are resolved before the code generation is done.
So to fix it the source type binding should set it tagBits during its construction.
Kent, do you think this is doable?
Comment 7 Olivier Thomann CLA 2004-12-14 17:32:30 EST
Created attachment 16609 [details]
Apply on org.eclipse.jdt.core.tests.compiler in HEAD

Adds two tests that checks it works with binary types (test101), but it does
not work with source types in two different files (test100).
Comment 8 Philipe Mulet CLA 2004-12-15 03:47:51 EST
Should hook annotations resolution into #completeTypeBindings stage.
Should invoke: ASTNode.resolveAnnotations(...)
using a blockscope (see current senders) 

Should only be done once hierarchies got connected.

Note that this will resolve entire annotations during #completeTypeBindings
stage, including initialization expressions carried by attributes, which is not
the purpose of this stage.
Problem is that if not resolving these, then we cannot compute the proper
annotation tagBits. We could only resolve the ones we care about at this stage,
and defer the full resolution until the AST is resolved (as currently).
Comment 9 Philipe Mulet CLA 2004-12-15 15:18:02 EST
Regression tests are: AnnotationTest#test102-103.

Implemented an alternate solution allowing to lazily resolve the forward
annotation reference. Clients are now using #getAnnotationTagBits() instead of
directly reading field: tagBits (for TypeBinding). 
This uses same approach as field constant lazy computation.

Comment 10 Philipe Mulet CLA 2004-12-15 15:18:18 EST
Fixed
Comment 11 Olivier Thomann CLA 2004-12-15 20:52:19 EST
Verified in 200412160010