Bug 196546 - [generics]Wrong handling of generics when weaving
Summary: [generics]Wrong handling of generics when weaving
Status: RESOLVED FIXED
Alias: None
Product: AspectJ
Classification: Tools
Component: Compiler (show other bugs)
Version: 1.5.3   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 1.6.1   Edit
Assignee: aspectj inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-07-14 15:58 EDT by Konstantin Khrapchenko CLA
Modified: 2008-06-09 23:16 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Konstantin Khrapchenko CLA 2007-07-14 15:58:23 EDT
I'm trying to adapt in my project a tool net.sf.OVal which is based on aspectJ. This tool simplifies checks of preconditions etc.

Its main aspect GuardAspect.aj is available here: http://oval.svn.sourceforge.net/viewvc/*checkout*/oval/net.sf.oval/src/net/sf/oval/guard/GuardAspect.aj?revision=134

I extended this aspect with my own:

import net.sf.oval.guard.GuardAspect;

public aspect KKPPGuardAspect extends GuardAspect {
  public KKPPGuardAspect() {
    super();
  }
}

and then with ant task iajc I compiled a common part of a project containing a class

import net.sf.oval.guard.Guarded;
import net.sf.oval.constraint.NotNull;

@Guarded
public abstract class FaultExampleBase<T extends Comparable<T>> {
  private final Class<T> clazz;

  protected FaultExampleBase(@NotNull final Class<T> clazz) {
    this.clazz = clazz;
  }

  public final Class<T> getComparableClass() { return clazz; }
  public String toString() { return clazz.getName(); }
}

the compiler produced a signature
const #224 = Asciz	<T:Ljava/lang/Object;:Pjava/lang/Comparable<TT;>;>Ljava/lang/Object;Lnet/sf/oval/guard/IsGuarded;;

when normally (without weaving) it should produce something like
const #37 = Asciz	<T::Ljava/lang/Comparable<TT;>;>Ljava/lang/Object;;

I believe that weaving has to result in adding IsGuarded interface but without modification of a generics part

the problem is that subclasses of FaultExampleBase cannot be compiled in separate projects having in a classpath the common because the signature of the class isn't recognized in a right way

for example, a class 
import net.sf.oval.guard.Guarded;
import net.sf.oval.constraint.NotNull;

@Guarded
public final class FaultExampleDerived1 extends FaultExampleBase<Integer> {
  private final Integer myParam;

  public FaultExampleDerived1(@NotNull Integer myParam) {
    super(Integer.class);
    this.myParam = myParam;
  }
}
is not compiled by the iajc that responds with an error:

     [iajc] error at public final class FaultExampleDerived1 extends FaultExampleBase<Integer> {
     [iajc]                                                 ^^^^^^^^^^^^^^^
     [iajc] D:\Home\PP\Common\XML\src\ru\kkpp\derived1\FaultExampleDerived1.java:9:0::0 The class file FaultExampleBase contains a signature '<T:Ljava/lang/Object;:Pjava/lang/Comparable<TT;>;>Ljava/lang/Object;Lnet/sf/oval/guard/IsGuarded;' ill-formed at position 22

so it complains on :P in a method org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment::getTypeFromSignature

ps. I tried this example as with aj 1.5.3 so with the latest available build (20070611)
Comment 1 Andrew Clement CLA 2008-06-09 23:16:29 EDT
can no longer access that linked file (my fault, I've left it too long) - but I believe this is fixed, I remember fixing the problem of P signatures getting into generated files some time ago, but I can't find the related bug report now amongst all the fixes that have gone in.