Bug 316547

Description Stephan Herrmann 2010-06-10 17:31:41 EDT

(originally from http://trac.objectteams.org/ot/ticket/163)

(continued from http://trac.objectteams.org/ot/ticket/161):

I could identify the following root cause:

  * class org.eclipse.jdt.internal.compiler.problem.AbortCompilation is loaded twice
      o the second loading is triggered from org.apache.jasper.compiler.JDTCompiler.generateClass(String[]) 
  * during the second transformation (we do have a bound role in the compiler adaptor), org.objectteams.transformer.util.TeamIdDispenser.clinitAdded(String) tells that we have already added the <clinit> method.
      o in fact this version of the class has no <clinit> method, thus the mentioned assumption in StaticSliceBaseTransformation does not hold. 

This raises several questions:

1.) Why is jasper loading another version of AbortCompilation?

  * Answer: the jasper plugin (org.apache.jasper_5.5.17.v200806031609.jar) contains a copy of the eclipse java compiler! 

2.) Why is the TeamIdDispenser keeping information after a class has finished loading?

  * ? 

In fact this is the first instance where the OTRE must cope with multiple versions of the same (adapted) class. Action items:

  * OTRE must cleanup state at given points in time (when? which state?)
  * OT/Equinox should detect that the class is loaded from a different plugin and thus avoid weaving (no aspect binding is declared for jasper!), roughly fixed as of http://trac.objectteams.org/ot/changeset/19192.
  * OT/Equinox must be able to distinguish classes not only by FQN but also by their defining bundle. 

----
today's comment: Much of this is actually covered by OTDyn, so this issue
should be re-checked once OTDyn is mature.