Re: [aspectj-users] Build problems / OOM in Eclipse

[Andy Clement <andrew.clement@xxxxxxxxx>]

No rules on that, whatever you prefer.

I'll take a look at the bug as soon as I can.

cheers,
Andy

On 15 April 2010 08:49, Martin Schafföner <the.shapht@xxxxxxxxxxxxxx> wrote:
> Andy,
>
> I filed bug 309336 for this problem.
>
> BTW: What's the general rule on this ML regarding posting style (top-level
> or inline answers)?
>
> Martin
>
>> -----Original Message-----
>> From: aspectj-users-bounces@xxxxxxxxxxx [mailto:aspectj-users-
>> bounces@xxxxxxxxxxx] On Behalf Of Andy Clement
>> Sent: Thursday, April 15, 2010 5:15 PM
>> To: aspectj-users@xxxxxxxxxxx
>> Subject: Re: [aspectj-users] Build problems / OOM in Eclipse
>>
>> Hi Martin,
>>
>> Please raise a bug for that (
>> https://bugs.eclipse.org/bugs/enter_bug.cgi?product=AspectJ  )- and
>> attaching projects (or emailing them to me) will be very helpful.
>> Declarations like the Op14 you showed are a little unusual (having all
>> those type variables) - so that may be leading to issues.  I have no
>> idea why switching from two declare warnings to one would cause a
>> problem.  I'll look out for the bug.
>>
>> cheers,
>> Andy
>>
>> On 14 April 2010 23:58, Martin Schafföner <the.shapht@xxxxxxxxxxxxxx>
>> wrote:
>> > Hi,
>> >
>> > I'm currently investigating the feasibility to apply AspectJ to a
>> larger
>> > commercial code base. While test-driving Eclipse and Ant tasks I
>> found some
>> > odd behavior. Maybe it's me, maybe it's a bug.
>> >
>> > The first thing I could drill down on is a build in Eclipse hanging
>> the
>> > entire IDE and eating ridiculous amounts of memory. The code with
>> which I
>> > can reproduce this problem is like this:
>> >
>> > We first have an interface which defines one method which throws
>> exceptions
>> > specified by generic type arguments, like this:
>> >
>> > interface Op14<Ret, E1 extends Throwable, E2 extends Throwable, ...,
>> E14
>> > extends Throwable> {
>> > Public Ret execute(String aArg) throws RemoteException, E1, E2, ...,
>> E14;
>> > }
>> >
>> > Then we specialize on the interface in a telescoping-style pattern to
>> reduce
>> > the number of exceptions that need to be specified:
>> >
>> > // Extend up to Op14
>> > interface Op1<Ret, E1 extends Throwable> extends Op2<Ret, E1, E1> {}
>> > interface Op0<Ret> extends Op1<Ret, RuntimeException> {}
>> >
>> > Then we have a separate class were the Op0 interface is implemented
>> in an
>> > anonymous inner class:
>> >
>> > Public class UseOperator {
>> > Void method() throws ...
>> > {
>> > Op0<String> f = new Op0<String>(){
>> > String execute(String aArg) throws RemoteException
>> > {
>> > System.out.println("Doh!");
>> > Return aArg;
>> > }
>> > f.execute("");
>> > }
>> > }
>> >
>> > And finally we have a simple aspect:
>> >
>> > Public aspect NoSystemStreams {
>> > Declare warning : get(java.io.PrintStream System.out) : "No
>> system.out";
>> > Declare warning : get(java.io.PrintStream System.err) : "No
>> system.err";
>> > }
>> >
>> > This still compiles fine. However, if I change the warning
>> declaration to
>> >
>> > Declare warning : within(com.msr..*) && get(java.io.PrintStream
>> System.out)
>> > : "No system.out";
>> >
>> > Compilation never finishes and starts eating what seems like
>> arbitrary
>> > amounts of heap (max Eclipse heap here was 2.5GB, and it did not
>> suffice!).
>> > It also seems like when reducing the inheritance depth to Op13, the
>> problem
>> > also disappears.
>> >
>> > This is a show-stopper as AspectJ cannot handle the grown code base.
>> If you
>> > like, I'll file a bug report with archives of working and failing
>> Eclipse
>> > projects.
>> >
>> > All of this has been tried with Eclipse 3.5.2 and both AJDT 2.0.2 and
>> > 2.0.3.e35x-20100410-1900; the problem occurs independently of the
>> weaving
>> > service being enabled or not.
>> >
>> > Any help or feedback would be appreciated!
>> > Martin
>> >
>> >
>> > _______________________________________________
>> > aspectj-users mailing list
>> > aspectj-users@xxxxxxxxxxx
>> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
>> >
>> _______________________________________________
>> aspectj-users mailing list
>> aspectj-users@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>