Community
Participate
Working Groups
Created attachment 115320 [details] Aspect, classes to weave, and compile.sh to run ajc I want to add the interface "edu.unm.cs.oal.sharing.Subject" to all classes of a project. For some reason ajc does not add the interface to some classes, as the weaved classes fail at runtime with an error like: ----SNIP---- Exception in thread "main" java.lang.IncompatibleClassChangeError at edu.unm.cs.oal.sharing.TrackSubject.ajc$interFieldInit$edu_unm_cs_oal_sharing_TrackSubject$edu_unm_cs_oal_sharing_Subject$__num_parents(TrackSubject.aj:4) at org.apache.xerces.dom.NodeImpl.<init>(Unknown Source) at org.apache.xerces.dom.ChildNode.<init>(Unknown Source) at org.apache.xerces.dom.ParentNode.<init>(Unknown Source) at org.apache.xerces.dom.CoreDocumentImpl.<init>(Unknown Source) at org.apache.xerces.dom.DocumentImpl.<init>(Unknown Source) at org.apache.xerces.dom.DeferredDocumentImpl.<init>(Unknown Source) at org.apache.xerces.dom.DeferredDocumentImpl.<init>(Unknown Source) at org.apache.xerces.parsers.AbstractDOMParser.startDocument(Unknown Source) at org.apache.xerces.impl.dtd.XMLDTDValidator.startDocument(Unknown Source) at org.apache.xerces.impl.XMLDocumentScannerImpl.startEntity(Unknown Source) at org.apache.xerces.impl.XMLVersionDetector.startDocumentParsing(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.DOMParser.parse(Unknown Source) at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source) at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:124) at net.sourceforge.pmd.RuleSetFactory.createRuleSet(RuleSetFactory.java:216) at net.sourceforge.pmd.RuleSetFactory.createSingleRuleSet(RuleSetFactory.java:178) at net.sourceforge.pmd.RuleSetFactory.createRuleSets(RuleSetFactory.java:111) at net.sourceforge.pmd.RuleSetFactory.createRuleSets(RuleSetFactory.java:126) at net.sourceforge.pmd.PMD.main(PMD.java:265) at dacapo.pmd.PmdHarness.iterate(PmdHarness.java:43) at dacapo.Benchmark.run(Benchmark.java:126) at dacapo.TestHarness.runBenchmark(TestHarness.java:302) at dacapo.TestHarness.main(TestHarness.java:242) at Harness.main(Harness.java:5) ----SNAP---- I attached the class files that I am trying to weave, together with a simplified aspect which only adds the interface. Using javap, one can easily see that org.apache.xerces.dom.NodeImpl does not have the interface added. See compile.sh inside of the tarball. Please let me know if you need additional info. Thanks! Reference: http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg09799.html
I ran your code and used -showWeaveInfo to tell me what was woven. It would appear that org.apache.xerces.dom.NodeImpl does not get woven with the new interface because the supertype does: javap -classpath out org.apache.xerces.dom.NodeImpl | head -1 public abstract class org.apache.xerces.dom.NodeImpl extends java.lang.Object implements org.w3c.dom.Node,org.w3c.dom.NodeList,org.w3c.dom.events.EventTarget,java.lang.Cloneable,java.io.Serializable{ grep org.w3c.dom.Node weaveinfo.txt Extending interface set for type 'org.w3c.dom.Node' (no debug info available) to include 'edu.unm.cs.oal.sharing.Subject' (AddInterface.aj) However, running javap: javap -classpath out org.w3c.dom.Node | head -2 Compiled from "Node.java" public interface org.w3c.dom.Node{ says it has not. That is because there is already another version of that class in the VM (in rt or somewhere in extensions) which gets loaded first and hasn't been woven. If I change the javap: javap -bootclasspath out org.w3c.dom.Node | head -2 public interface org.w3c.dom.Node extends edu.unm.cs.oal.sharing.Subject{ public static final short ELEMENT_NODE; I see the version in the output folder has been woven.
Right, I do get the same results, knowing where to look now. I didn't think that the classpath was interfering! I actually used to check the results with jclasslib, but then used javap because it was more convenient to use. I guess both have their value, as javap was seeing exactly the same class as java at runtime - and thus the same error. Andy, thanks a lot for testing this! I really appreciate it. And sorry for reporting something that didn't turn out to be an error with aspectj - it just really looked like it :-). I'm closing the bug.
