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 <[email protected]> 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: [email protected] [mailto:aspectj-users- >> [email protected]] On Behalf Of Andy Clement >> Sent: Thursday, April 15, 2010 5:15 PM >> To: [email protected] >> 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 <[email protected]> >> 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 >> > [email protected] >> > https://dev.eclipse.org/mailman/listinfo/aspectj-users >> > >> _______________________________________________ >> aspectj-users mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/aspectj-users > > _______________________________________________ > aspectj-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/aspectj-users > _______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users
