Bug 92880 - @AJ PTW
Summary: @AJ PTW
Status: RESOLVED FIXED
Alias: None
Product: AspectJ
Classification: Tools
Component: Compiler (show other bugs)
Version: DEVELOPMENT   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 1.5.0 M3   Edit
Assignee: Alexandre Vasseur CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-04-27 03:54 EDT by Alexandre Vasseur CLA
Modified: 2005-09-27 09:28 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexandre Vasseur CLA 2005-04-27 03:54:15 EDT
implement PTW for @AJ aspects
so far delayed to make sure PTW in code style was not evolving
Comment 1 Alexandre Vasseur CLA 2005-04-29 06:25:05 EDT
Spotted some defects in current impl - no matter the style (code or @AJ) when
impl. the @AJ side of it.

- PTW implies that the aspect has:
private [transient] Map instances;
public Set getInstances() {..}
I think we should not use "instances" but some mangled name to avoid clash with
a user field in the aspect (=> compiler + weaver to align both style)

- the private static <aspecttype> ajc$getInstance(Class class1) throws Exception
method is catching Exception to simply rethrow it. The try catch is thus useless

- field     private static Throwable ajc$initFailureCause is added, while not
used (same for perCflow by the way)

Andy / Adrian I d like to hear your comments on those.
Comment 2 Alexandre Vasseur CLA 2005-05-04 04:08:10 EDT
assign to Adrian for comments in the "instances" field name
Comment 3 Andrew Clement CLA 2005-05-04 04:45:02 EDT
Hi Alex,

I can't quite tell if the first of your problems is because of how you have to
do @AJ weaving?

> - PTW implies that the aspect has:
> private [transient] Map instances;
> public Set getInstances() {..}
> I think we should not use "instances" but some mangled name
> to avoid clash with a user field in the aspect (=> compiler + weaver to 
> align both style)

For code style, why does the aspect need to store a Map?  For pertypewithin the
aspect instance is stored in the static state of the object for which the
instance is created?
In the current impl, each 'matched' object gets something like this added to it:

public static X ajc$X$localAspectOf() {
  return ajc$X$ptwAspectInstance;
}

private static transient X ajc$X$ptwAspectInstance = 
  X.ajc$createAspectInstance("A");

The implementation of aspectOf in the aspect is then:

    public static X aspectOf(Class class1) {
        try {
            X x = ajc$getInstance(class1);
            if(x == null) throw new NoAspectBoundException("X", null);
            else          return x;
        } catch(Exception exception){
            throw new NoAspectBoundException();
        }
    }

I agree that all names should be mangled to prevent clashes - and so far they are.



> - the private static <aspecttype> ajc$getInstance(Class class1) 
> throws Exception method is catching Exception to simply rethrow 
> it. The try catch is thus useless

I suspect the catch block should be returning null so the caller can report the
NoAspectBoundException rather than a grotty reflection exception.  good spot.

> - field     private static Throwable ajc$initFailureCause is added, 
> while not used (same for perCflow by the way)

ajc$initFailureCause is used to record the original reason why an 
aspect instance couldn't be created (see code for a singleton instance to 
see exactly how its used) - it is currently not set - it could be used in a
slightly different way for PTW - it *could* record any exception that occurs in
the ajc$getInstance() and then be passed as the 2nd param on the
NoAspectBoundException ctor in the aspectOf() method.


The remaining bit of impl that I know isn't finished is that:

private transient String ajc$withinType;

is set but isn't accessible to the end user - which they might want to get hold
of - it will tell them the type for which this aspect instance exists.
Comment 4 Alexandre Vasseur CLA 2005-05-04 05:06:04 EDT
ha thanks. I actually impl my stuff based on the sample and did not see that
this instances / getInstances was actually a real method in the aspect source
(PerTypeWithinTests, AJDKExamples)
So I ended up generating this field and method for @AJ PTW aspect...

for the exception: let me know if we return null or just throw it again. I need
to miror that in the @AJ impl

for the ajc$initFailure: ok so right now it is not used in PTW and Percflow but
we keep it just in case as you say.
Comment 5 Andrew Clement CLA 2005-05-04 05:21:15 EDT
Returning null would seem the right thing to do for the catch block - but I'm
not sure when I'll get a minute to fix it - you could leave this bug open to
track fixing it.  Maybe I'll get Andrew to do it - he could do with some
experience in that area...
Comment 6 Andrew Clement CLA 2005-08-15 09:59:49 EDT
I've fixed the compiler layer to generate code that returns null if an exception
occurs in getInstance() - i've also modified the signature of getInstance() so
it no longer defines that it throws an exception.
Comment 7 Alexandre Vasseur CLA 2005-08-16 11:29:28 EDT
todo align for @aj
Comment 8 Alexandre Vasseur CLA 2005-08-17 03:34:42 EDT
done in @AJ for aj$getInstance
close when M3 ship
Comment 9 Alexandre Vasseur CLA 2005-09-27 09:27:31 EDT
was M3 remind
Comment 10 Alexandre Vasseur CLA 2005-09-27 09:28:40 EDT
was M3 remind