The AspectJ pointcut parser is a reusable component (used in Spring
Framework, for example).  However, it does have a well defined set of join
points which may or may not make sense in the context of another language
(most likely more would be needed too).

The AspectJ pointcut matcher is a reusable component.  If you can conjure up
something that looks like a join point (using whatever means you like), it
will tell you whether a pointcut matches that and what any required runtime
test would be.  The AspectJ weaver is an example of something that consumes
bytecode and presents pieces of it as candidates to the pointcut matcher.
We are progressing with also implementing a Eclipse JDT source level system
that would allow AspectJ pointcuts to be matched against Java source (so
matching without the need for compilation).

Personally I'm spending more time with Groovy right now than Scala.
However, in both cases AspectJ will have issues with the compiled code.  We
already have an open bug about being unable to weave Scala code and I know
that groovy code does a huge amount of transformation to produce its class
files so when AspectJ would be looking for join points, they would be very
hard to pick out.  I would estimate it is a large amount of work to get
weaving and the semantics of that weaving consistent across these languages.

Andy

2009/7/20 Ashley Williams <[email protected]>

> I second that question. Am I right though in thinking that AspectJ is
> really about targeting join pointsat the byte code level? If this is
> remains true - and I can't see how it would be practical to change this -
> then you'd always have to be aware of how the scala source code for example
> gets de-sugared.
>
> I'd be very interested in tighter integration between scala and AspectJ.
>
> - Ashley
>
> On 20 Jul 2009, at 14:02, Michael McCray wrote:
>
> Hi All,
>
> I was wondering if it is required that AspectJ is tied to the Java
> Language?  I see that is what the J is for, but there are some new languages
> like JavaFX and Scala that I don't think have supporting aspect extension
> languages.  There is http://functionaljava.org/, a variant of Java that
> supports closures and other functional language concepts.  What if AspectJ
> could become AspectJVM and support other JVM languages?  I understand LTW
> can do much of what I ask, how far off is LTW from a real integration?  I
> mean it would be nice to write my aspect code using other language features
> as well at least this would not be possible until the aspectj language
> specification changed.
>
> Why not add closures to AspectJ to support it's usage in aspects?  How is
> it decided to evolve the language?
>
> Mike
>
> _______________________________________________
> 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

Reply via email to