Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [aspectj-users] Build problems / OOM in Eclipse

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



Back to the top