Is it possible to have a Scala Maven project and weave AspectJ aspects at compile-time within the Scala classes?
I've been able to get load-time weaving to work but so far no success with compile-time.
The aspects are simply not woven into the Scala classes. From what I understand, compile-time weaving requires a specific Java compiler (AspectJ Compiler aka ajc). It is my understanding that ajc cannot compile Scala.
Is there an ajc equivalent for Scala? Or perhaps another way to get compile-time weaving to work with Scala?
Answer 1 isn't true compile-time weaving - it's binary weaving of already-compiled classes. It wouldn't work, for instance, if your scala classes needed the aspects to compile properly. I think the issue of compile-time weaving in scala is still an open question.
We agree with the assessment by the original poster that ajc is unlikely to know how to compile scala.
How about using AJC's -inpath switch? It accepts .class files in directories or JARs and weaves into them. Your Scala compiles to .class files, so that ought to work. No doubt you have the AJC docs, but here's a link.
Related
what should be the correct maven dependencies to declare if i want to use org.scalamock.generated.GeneratedMockFactory?
I have a scala project which depends on scalatest_2.10 version 2.0.M5B and scalamock-scalatest version 3.0.1 and it looks like the org.scalamock.generated is in neither of them.
kind regards
marco
org.scalamock.generated.GeneratedMockFactory is a trait that is generated by the Scalamock compiler plugin for Scalamock 2 (for Scala 2.9 or older). In scalamock 3 (for Scala 2.10/2.11), the use of the compiler plugin is replaced by macros, so that Scalamock now supports the following two types of mocks :
Macro mocks, using org.scalamock.scalatest.MockFactory
Proxy mocks, using org.scalamock.scalatest.proxy.MockFactory
Please note that macro mocks may fail (at compilation) when trying to mock some complex traits, but they are fully type-checked and have nicer syntax - so it's a good idea to use macro mocks as much as possible, and fall back to proxy mocks when they don't work, according to Scalamock's author. He also has a nice step-by-step guide to using Scalamock 3 (with macro mocks) here.
I thought ever it could be very nice, if the weaving and the actual compilation happened in different steps. Is there any not-really-well-known flag, or some such alternate solution to generate the intermediate .java code?
Anyways, weaving happens on the classes, or on the java source?
Weaving happens on the bytecode.
You might be able to disassemble the resulting bytecode, though.
Dave is right that weaving happens on bytecode (been that way since version 1.2). But you are still able to compile things separately and do weaving later. Build your regular java code as normal into a jar, then build your aspects into an aspect library, then just apply one to the other:
ajc -aspectpath myaspects.jar -inpath mycode.jar -outjar mywovencode.jar
Effectively that is compiling and weaving happening in different steps.
Testing runtime behavior is very well documented but with the advent of powerful type systems and macro system one might be interested in testing compile-time behavior.
For instance when writing a library that provides compile-time guarantees. Say I'm building a set of test matchers and I want to make sure a matcher is as type-safe as I claim it to be.
List(1,2) must beEqualTo(Set(1,2)) // should fail at compile-time
I can see in the scala compiler project that most of the tests are functional tests where the compiler output is asserted by comparing it with a reference file.
Is there a convention for such tests? An SBT plugin?
Thanks
i need find all subclasses which mixing some trait (i won't do this in a runtime). I know tool written in scala (ClassUtil) but this tool is slow. Also I know one tool written in java (fasters than ClassUtil), but if I have choice I wouldn't rather using external libraries - so my question is: scala 2.10 have support resolving my problem?
Several questions here:
Does ajc change all the classes it compiles (even non-aspect ones)? What if I compile only aspect classes ant then put them in the same classpath with the common ones?
Does the ajc-compiled project perform faster then the one that uses load-time weaving?
What if I need to write a library, that does tracing with AspectJ, and then I want this library to work with ANY project? Is load-time weaving the only option in this case?
ajc (compile time) will only change classes that are affected by aspects. Remember, ajc is an extension of a Java compiler (to be precise, it is based on Eclipse 3.3's JDT compiler). So, it will compile all your Java classes as would a normal Java compiler. It will then additionally weave all classes that are affected by an aspect. If you compile your aspects separately from your non-aspects then there will be no compile time weaving going on and your aspects will not have any affect. However, you can put your aspects on the aspect path of the compilation of your non-aspects (if your non-aspects are compiled by ajc). This will allow your non-aspects to be woven by your aspects.
Start-up time under CTW is much better than LTW, but after all classes are loaded, speed difference should be negligible. The reason is that under LTW, all classes are woven when they are loaded. This means that classloading requires the additional step of weaving which is not necessary under CTW.
No. As mentioned above, you can add the aspects to your aspect path of the second project, and then they will be woven during compilation.
More on Aspect path:
http://www.eclipse.org/aspectj/doc/released/devguide/ajc-ref.html