Re: [ajdt-dev] Can't determine superclass of missing type (was Weaving

[Andy Clement <andrew.clement@xxxxxxxxx>]

Firstly, i apologise for jumping in mid thread. it just caught my eye this morning, hope I'm not contradicting anyone.

> The weaver seems to want to have it on the inpath, which I'd have
> thought shouldn't be necessary (surely we can weave a jar in isolation
> from those it depends on).

As a specific example, suppose I wrote 

before(): call(SomeInterface+.new(..)) {}

Then we had the code: PaneLayout paneLayout1 = new PaneLayout();

How would I know if PaneLayout implements SomeInterface?  AspectJ needs to see it, and see what it's supertypes are.  Effectively for completeness it ought to have access to everything that was used to build the code.  Now you can rework your pointcuts/advice to limit how much exploration of the type system is necessary by AspectJ - it will only analyse what it needs to.

That said, there might well be bugs where too much analysis is done, or further possibilities for optimization - but we would need to go into deep details of each case - feel free to raise a few on AspectJ bugzilla if you want to explore them, but I'll need to know quite a bit of info.

We also have an enhancement on the 'back burner' that situations like this would result in extra runtime tests.  So if I can't find a type at compile time, all I can do is insert a test for what I wanted to confirm into the code - but that is paying a heavy price at runtime because the class wasn't passed in earlier...

> Inpath seems rather broken, and my only solution would seem to be to put
> everything in the same project, which I've already had, and found
> horrendously slow.

that doesn't sound right.  In order to satisfy any dependencies (like PaneLayout above), AspectJ only needs access to the type from the classpath, it doesn't need it on any inpath or aspectpath.

cheers,
Andy.

2009/3/2 Neale Upstone <neale.upstone@xxxxxxxxxx>

Thanks Andrew,

I think we've got some corner cases here that need looking at, which
I'll post as separate threads.


I set up as you suggested (which is thankfully what I'd guessed) and
there's another complication.  There is another library in 'base'
jbcl.jar (mmm... ;), which I don't want to weave into.

The weaver seems to want to have it on the inpath, which I'd have
thought shouldn't be necessary (surely we can weave a jar in isolation
from those it depends on).

The error I get is:
can't determine superclass of missing type
com.borland.jbcl.layout.PaneLayout
when weaving type JDL_ColorChooser
when weaving classes
when weaving
when batch building BuildConfig[C:\Apps\eclipse\emini-facade] #Files=76
AopXmls=#0
 [Xlint:cantFindType]

The only use of PaneLayout is simply the field: PaneLayout paneLayout1 =
new PaneLayout();


Cheers,

Neale





> -----Original Message-----
> From: ajdt-dev-bounces@xxxxxxxxxxx
> [mailto:ajdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Andrew Eisenberg
> Sent: 27 February 2009 18:09
> To: ajdt-dev@xxxxxxxxxxx
> Subject: Re: [ajdt-dev] Weaving into a "read-only" project
>
> If I understand what you want to do correctly, this should work:
>
> 1. put base on the inpath of base-facade.  If itext.jar is a required
> library of base, then it should be included in the inpath.
> Essentially, this means that all of base's class files are sent to
> base-facade's weaver and woven classes are spit out in the default
> output location.
>
> 2. If you want, you can specify an inpath-out-jar in the AspectJ
> project build path page in the inpath tab.  This will separate the
> woven class files from base-facade from the woven files of base.
>
> 3. Then app should put base-facade as a required project (and possibly
> the inpath out jar if you specified one).
>
> Please let me know if this works for you.
>
> On Fri, Feb 27, 2009 at 9:55 AM, Neale Upstone
> <neale.upstone@xxxxxxxxxx> wrote:
> > I have 3 Java projects with some interesting dependencies, and I'm
> > struggling to understand how to let AJDT know what to do:
> >
> > The projects are app, base-facade, and base.
> >
> > 'base' is read-only.
> >
> > We want to weave into base, and also into at least one of
> it's referenced
> > libraries (itext.jar in this case), so we have a project
> that depends on
> > base, called base-facade.
> >
> > 'app' does nothing with aspects, and wants to see
> base-facade and a woven
> > version of base and any libs in base that were woven into.
> >
> > Ideally:
> > - I don't want base to be an AJ project, as I just want to
> bring it into my
> > workspace.
> > - I don't want to be running any ant scripts
> >
> > I've solved the problem for the build server (using iajc to
> weave base and
> > itext.jar).
> >
> > Cheers,
> >
> > Neale
> >
> >
> **********************************************************************
> >
**********************************************************************
IMPORTANT NOTICE.
Confidentiality:  This e-mail and its attachments are intended for the above named only and may be confidential.  If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this e-mail and highlight the error.
Security Warning:  Please note that this e-mail has been created in the knowledge that Internet e-mail is not a 100% secure communications medium.
We advise that you understand and observe this lack of security when e-mailing us.
Viruses:  Although we have taken steps to ensure that this e-mail and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free.
Monitoring and Scanning:  Cambridge Cognition has monitoring and scanning systems in place in relation to emails sent and received to: monitor / record business communications; prevent and detect crime; investigate the use of the Company's internal and external email system; and provide evidence of compliance with business practices.

Cambridge Cognition Limited
Company Registration Number 4338746
Registered address:
Tunbridge Court
Tunbridge Lane
Bottisham
Cambridge
CB25 9TU
UK
**********************************************************************

_______________________________________________
ajdt-dev mailing list
ajdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ajdt-dev