Ticket #63 (closed defect: fixed)
Wrong transformation for inner classes
| Reported by: | Bernhard Haumacher (haui at haumacher dot de) | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | 1.04d |
| Component: | JP trafo | Version: | |
| Severity: | normal | Keywords: | |
| Cc: |
Description (last modified by hauma) (diff)
Access to variables of the enclosing class from inner classes is not possible and gives an error in transformed code.
Workaround
Write full qualified access patterns for the variable like in the following example:
class A {
int x;
class B {
void foo() {
A.this.x = 13;
}
}
}
Evaluation
There are two options to fix this issue:
- The computation of access patterns during the JavaParty transformation must be adapted to inner classes.
- The order of the transformation steps form remote classes and inner classes must be changed.
Since the inner class trafo is no source to source transformation, it cannot be done before the JP trafo, because the JP trafo expects source code and generates source code.
Solution
The computation of the full qualified name for all variable accesses was changet in order to account for inner classes.
Problem
All variables are now accessed with fully qualified names (after the remote class transformation). But final variables can not be initialized with a fully qualified name.
Variables of remote classes are problematic, because the the remote class changes its name during the transformation. But remote classes are not supported at all, so this fix should work in most cases.
Test
jp.test.TestInner
See also
Attachments
Change History
comment:1 Changed 8 years ago by hauma
- Status changed from closed to reopened
- Resolution fixed deleted
- Description modified (diff)
comment:2 Changed 8 years ago by hauma
- Status changed from reopened to closed
- Resolution set to fixed
Solution
Generate accesses as relative as possible. Only accesses to variables of enclosing classes must be fully qualified. Accesses to instance variables of the same class can be relative to this. See: [2822].

The fix in [888] for accesses to final variables is broken, because it does not consider to witch class the variable belongs. The variable x in the following example was referenced through this.x in B: