Re: [aspectj-users] Future of AspectJ

[Michael McCray <mike@xxxxxxxxxxxxxxxxx>]

I am most interested in:

AspectJ or Java
Groovy or Scala
Clojure, JRuby, or other misc.

In the above list, Java seems stuck in terms of closures for example,
so this puts AspectJ in an adverse situation.  So I look towards Scala
for continued use.

If we talk about Aspect* to support each of the other languages, then
that would be a fork or an add on or something of the core AspectJ
code.  The ideal aspect solution would be for AspectJ to lead the
multilanguage aspect compatibility.  AspectJ is already a mixed
language approach, ok, sure you can simply use AspectJ compiler, but I
find that I tend to write aspect code separate from Java code that is
non-aspect.  In my head I feel that with AspectJ I am freed to write
good clean Java code that isn't cluttered by all sorts of external
concerns.  So there is this split anyway.  It would be really nice if
these could be simply chosen as desired, some weird (bytecode oriented)
any class can call any (other languages) class, can be advised by any
language.  The joint groovy compiler and aspectj compiler (aspectj or
plain java) is a good example of this.

I think this picture is complicated by these options:
write pointcut in x language
write advice in x language
write aspect in x language (style of the language - scala syntax, vs, java style, vs. ()s clojure style).
Maybe
I am overgeneralizing, but It would seem that the parser that compiles
the aspect would only have to parse the x new language, and transform
into the existing AspectJ AST model.

Mike

On Thu, Jul 23, 2009 at 6:35 AM, William Louth (JINSPIRED.COM) <william.louth@xxxxxxxxxxxxx> wrote:

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.

_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users

-- 
Michael D. McCray
Consultant - Technology Partners, Inc.
President - Object Nirvana, Inc.
Maker of
My People Database
- automation for what you do with your friends and family, and a place to store your stories and information.

Website: http://www.mypeopledatabase.com/
Transcendental Beans Database
- an aspect oriented database system,
   the future of data storage
Website: http://www.objectnirvana.com

Open source version: http://transcendentalbeans.dev.java.net/
Tweat Market - Twitter Dating Client
http://www.tweatmarket.com/

Blog: http://aodbms.blogspot.com
Email: mike@xxxxxxxxxxxxxxxxx
Twitter: http://twitter.com/seagullmike