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
