Re: [aspectj-dev] New build errors in sept 11 release of ajc

["Adrian Colyer" <adrian_colyer@xxxxxxxxxx>]

I think this is the tightening of a
compiler loophole rather than a newly introduced bug - but since this program
has been working since 1.0.6 I'd like Jim to verify my assessment!

The containerLoads pointcut is declared
as follows:

   public
pointcut
containerLoads(ContainerLoader loader,
         
               
               
    ContainerDescriptor containerDesc ): .....;

Then the AspectBug aspect refers to
it when defining the loadExecutions pointcut:

        protected
pointcut
loadExecutions( Key key ):
         
      ContainerLoader.containerLoads( *, key);

You can't change the signature of the
loadExecutions pointcut since you are defining an abstract pointcut with
this signature from a super-aspect. However, whilst it is true in your
program that a ContainerDescriptor *is an* AbstractCaching.Key, it is not
guaranteed to be true that an AbstractCaching.Key *is a* ContainerDescriptor.
Hence according to the static type checking, Key is indeed an incompatible
type for containerLoads. The minimal change to "port" the code
to 1.1.1 is to use args to assess the runtime type:

        protected
pointcut
loadExecutions( Key key ):
         
      ContainerLoader.containerLoads( *, ContainerDescriptor
) && args(key);

(please let me know if your system
works as intended with this change). What I dislike about this solution
is that it relies on knowledge of the 'implementation' of the containerLoads
pointcut. There may be a more invasive redesign of the application that
avoids this problem.

-- Adrian
Adrian_Colyer@xxxxxxxxxx

Macneil Shonle <mshonle@xxxxxxxxxxx> Sent by: aspectj-dev-admin@xxxxxxxxxxx 12/09/2003 09:19 Please respond to aspectj-dev

To:        <aspectj-dev@xxxxxxxxxxx>         cc:                 Subject:        Re: [aspectj-dev] New build errors in sept 11 release of ajc

I made a small test case for the problem I spoke about
earlier.
First, here are the versions of AspectJ I'm using (this is a bash
shell under cygwin on Windows XP):

~> CLASSPATH='C:\aspectj1.0\lib\aspectjrt.jar'
/cygdrive/c/aspectj1.0/bin/ajc -version
ajc version 1.0.6 (built Jul 24, 2002 6:21 PM PST) running on java
1.4.1_02
~> CLASSPATH='C:\aspectj1.1\lib\aspectjrt.jar' /cygdrive/c/aspectj1.1/bin/ajc
-version
AspectJ Compiler 1.1.0
~> CLASSPATH='C:\aspectj1.1.1rc1\lib\aspectjrt.jar' /cygdrive/c/aspectj1.1.1rc1/bin/ajc
-version
AspectJ Compiler 1.1.1rc1
~> CLASSPATH='C:\aspectj1.1.1\lib\aspectjrt.jar' /cygdrive/c/aspectj1.1.1/bin/ajc
-version
AspectJ Compiler 1.1.1

For all four of these compilers, I give them the AspectBug.java
file
(which is attached):

~> CLASSPATH='C:\aspectj1.0\lib\aspectjrt.jar'
/cygdrive/c/aspectj1.0/bin/ajc AspectBug.java
~> CLASSPATH='C:\aspectj1.1\lib\aspectjrt.jar' /cygdrive/c/aspectj1.1/bin/ajc
AspectBug.java
~> CLASSPATH='C:\aspectj1.1.1rc1\lib\aspectjrt.jar' /cygdrive/c/aspectj1.1.1rc1/bin/ajc
AspectBug.java
~> CLASSPATH='C:\aspectj1.1.1\lib\aspectjrt.jar' /cygdrive/c/aspectj1.1.1/bin/ajc
AspectBug.java
C:\Documents and Settings\Macneil Shonle\AspectBug.java:7 incompatible
type, expected ContainerDescriptor found BindingTypePattern(AbstractCaching$Key,
0)

1 error

As you can see, only the final run (with the Sept
11 build of
ajc) do we see the "incompatible type" error. If this is not
a
regression but a desirable result, how should the code be ported?

Thanks,
Macneil





#### AspectBug.java has been removed
from this note on September 12, 2003 by Adrian Colyer