[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[List Home]
|
Re: [aspectj-users] Future of AspectJ
|
- From: "William Louth (JINSPIRED.COM)" <william.louth@xxxxxxxxxxxxx>
- Date: Thu, 23 Jul 2009 13:35:41 +0200
- Delivered-to: aspectj-users@eclipse.org
- User-agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
JXInsight which has a set of extensions to its Probes Open API based on AspectJ already supports this kind of instrumentation (and metering) of JRuby Ruby execution engine (VM).
http://williamlouth.wordpress.com/2008/10/14/cross-language-profiling-with-jxinsight-jruby-to-ruby/
We are also planning on extending this multi-language support to other JVM languages.
Date: Thu, 23 Jul 2009 09:50:30 +0100
From: Ashley Williams <ashpublic@xxxxxxx>
Subject: Re: [aspectj-users] Future of AspectJ
To: aspectj-users@xxxxxxxxxxx
Message-ID: <979DB25A-82C4-48DE-B8DC-972196A6518A@xxxxxxx>
Content-Type: text/plain; charset="us-ascii"
Traits are a good feature but they are localized to the class that
does the extending.
AspectJ is still useful for targeting a whole set of classes, say in
the same package
or marked with an annotation. What would be great is if the aspect
could then add the
mixin scala-style using the trait api - but that would require
"AspectS" as mentioned
by Miles.
Besides AspectJ can do a lot more than simulate mixin behavior.
Personally I
think there will always be room for aspectj in any of the jvm
languages because
of its close and honest proximity to the bytecode and because it
provides a way
of encapsulating otherwise scattered host language constructs whatever
they
might be.
Maybe we need AspectJVM, AspectJ, AspectS, AspectG and AspectC - the
last one being for clojure - although It would be interesting to see a
jvm language
absorb an aspectj flavor directly into its compiler.