Community
Participate
Working Groups
In a number of cases tools are getting confused over generated aj members that are "aj-synthetic" but not marked with the synthetic attribute (because in the past, this has upset other tools). The most recent example was a JAXB posting on the list - by having a perthis() clause in an aspect that matched a type with JAXB 2 annotations the user was no longer able to use JAXB. This is a serious issue, and will prevent the usage of JAXB 2 with any type into which we introduce properties as aj-synthetic members. The JAXB 2 solution to ignore such fields is to annotate them with @XmlTransient, but since the field does not exist in the user program they can't even do this!
would be good to do this in 1.5.2 if there is time...
Also note, making these members truly synthetic will presumably make them disappear from java.lang.reflect access - which the AjTypeSystem currently depends on... some thinking to be done there.
I ran into this issue with the Emma code coverage tool before, so this option would be valuable to try out. But it would be much less attractive if it broke the AspectJ reflection access...
Note, a related issue has now been seen "in the wild" with Hibernate Entity Manager mappings. On the reflection API point I raised earlier, we need to be careful, but I don't think there's going to be a big problem. The members that reflection most needs to see are members within aspects - we can keep those as regular members. It's the members we add into woven types (for private ITDs, per-clauses, @DeclareParents, etc.) that really need to be truly synthetic, and AjTypeSystem does not depend on visibility of any of those.
good news, bad news. Good news is that the synthetic changes will absolutely not affect the AjTypeSystem. Bad news is that synthetic members are still fully visible via reflection (I'd assumed they wouldn't be, but for no good reason it transpires). In JDK 1.4 and below, there isn't even any way you can tell that they are synthetic. JDK 1.5 adds an isSynthetic() operation so you can tell :- let's hope JAXB et. al. take note of it (since they're all annotation driven, they are at least on JDK 1.5). I've been able to get the synthetic flag/attribute on the relevant members with very little effort - full test suite still passes. Need to do some more checking on members we create in the front-end compiler before checking in.
I've changed the compiler to add the synthetic attribute / flag (as appropriate for JDK 1.4/1.5) to all synthetic aspect members. Tests show that this seems to be working very well. I wrote some aspects from hell that exercised every language feature, advised the same target type with all of them, and then ran the results through Emma without any issue. Only slight nit is that Emma still showed the synthetic members in its coverage report (which looks a little ugly) - but it certainly worked.
fix committed in tree
now available in latest build
See bug #148727 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=148727) I don't think it's reasonable to mark API methods like aspectOf and hasAspect as synthetic, which prevents seprate compilation of code that refers to these methods from working.
Also, I found cases in our code where Emma was still complaining about AspectJ generated classes not having debug information. If there's a fix to iajc to allow keeping synthetic markers, I will investigate this further.
I've read that emma used to not recognized Java5 classes, and so it didn't know that with Java5 synthetic became a bit flag and not an attribute... AspectJ will be correctly making it a bit flag when producing Java5 level classes.
Changing OS from Mac OS to Mac OS X as per bug 185991
