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
