Community
Participate
Working Groups
When {public} static final fields are declared on an interface or a class from an aspect, they are not treated as constants in case statements (as static final fields declared in/on classes are). Perhaps the same result with compile-time String concantenation, (...others?) You can decide if this is a bug or an undocumented part of the implementation limitations or semantics. If it's a bug, I can submit a test case.
I think this is a limitation because Java won't allow final fields to be initialized outside of their respective initializer and ITD fields need to be initialized in the defining aspect. final static ITD fields seem bogus to me but we can't take them away. Perhaps they should be "deprecated". >Perhaps the same result with compile-time String concantenation, (...others?) What does this mean?
I'm not sure it's a limitation imposed by Java or bytecode weaving, but it might be a limitation of our implementation. (Not being an expert in any of these, I am mostly speculating.) If, or since, public static final constant expressions (compile-time constants) must be available to the client when the client is compiled, then the client is in the scope of the code the implementation controls. If that's true, it seems like ajc can inline the constant into the client. So I don't believe it is a limitation imposed by Java. The problem could lie in separating compilation and weaving or in making them possible on a per-class basis. Normally weaving surfaces join points and adds members and parents. Here we would be asking the weaver to also fold in inline references to compile-time constants, which seems possible but not desirable. Resolution of any constant expression involving a compile-time constant declared on another type by an aspect would have to be deferred to the weaver. The compiler check on constant expressions would have to be updated to permit this delayed resolution. The weaver would have to do the re-compilation necessary to resolve the entire constant expression (and update the constant table). While not good, it seems feasible. Nor does it seem to prohibit per-class weaving, since such constants are all defined in aspects which by hypothesis are all available to the weaver. So I don't think it is a limitation imposed on any implementation that has a separate compiler and weaver and does per-class weaving. It may, however, be a limitation of our implementation. If this behavior stands, I think it shouldn't be deprecated, but that we should just document that fields declared in an aspect on other types are never treated as compile-time constants. The declarations are very useful, but constant expressions are rarely required. (wrt initialization scope, AspectJ I think requires that a static final field be initialized in its declaration, since aspects don't (but should?) have a way to declare a static initialization block on another type. Workarounds there include defining a static method to do the work, given any static fields that are defined earlier in the file (though the order relative to fields defined in the type itself or other aspects is undefined).)
This is an undocumented limitation of the current implementation. Constant fields are a surprisingly complicated part of a Java compiler, and it didn't seem to be worth the effort to make ITD fields work with this mechanism. I agree with Matthew that final static ITD's are pretty ugly. Personally, I don't think there's ever a good design reason to use a static ITD, but it's extremely unlikely we'd take away this feature since I'm also sure there are people using it. I'm marking this bug as a P4 enhancement request as a limitation we might consider removing for some future release.
We're not going to get to this in AJ 1.5.0. Marking as "LATER" for consideration in 1.5.1 and future release planning.
reopened for another look - but not sure what we can do without spending some time thinking it through.
review for 1.5.4 - but may not make that release
