I suppose we should continue this in another thread.
> Hi, > > > > > > > Why don't you create some developer documentation so that it's easier for > people to help you. > > > > > > I think you know what I'll say here: time. I'll try and find some to > improve the situation - there are docs (e.g. > http://www.eclipse.org/aspectj/doc/released/faq.php#q:buildingsource ) > but they haven't had any love in a while > . I agree that of course it would help. Mostly those keen enough to > contribute actually ask me and I email them the basics of what they need, I > just don't find the time to nicely integrate that into the docs. > > > > > > > > I think that at least a document that explains how to build AspectJ is > gonna be very useful. > > > > > > > Here is what I sent to the last person that asked: > > > > > > > Building it: > > > - go into the 'build' module > > > - copy sample.local.properties as local.properties, edit it if you want > particular version stamps. > > > - run 'ant' to build it > > > - the output appears in a new directory at the org. > aspectj level called 'aj-build'. In 'dist' is a distribution all > packaged. In 'dist/tools/lib' are the individual jars like weaver. > > > > > > That doesn't run the tests though, untangling how that happens is > trickier. I typically run them all in eclipse (RunTheseBeforeYouCommitTests). > In keeping with having limited time the build process is a little antiquated. > Per > http://www.eclipse.org/aspectj/doc/released/faq.php#q:buildingsource you > effectively: git clone, import all the projects, set the missing environment > variables and you are good to go (it'll build and tests should be runnable). > > > > > > I'm annoyed we don't have nice OSGi manifests too - a few issues exist > around on that: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=338034 > > > > > > If you think you'll have time to help with issues like the OSGi > manifests, I'll really try and find the time to get the docs correct? > > > > > > cheers, > > > > Andy > > > > > > > > > > On 8 January 2013 03:45, M. P. > wrote: > > > Hi Andy, > thanks for your answer. > I spent a couple of hours looking at the weaver source code yesterday. > At first it seemed relatively clear how to detect arithmetic instructions but > when I continued I realized that adding a join point is going to be a shotgun > surgery. > Apparently you're the only one who does something for AspectJ, aren't > you? At least that's what the commit messages suggest. Why don't you create > some developer documentation so that it's easier for people to help you. I > think that at least a document that explains how to build AspectJ is gonna be > very useful. And if you add a couple more documents explaining what's what > and where plus some architectural description AspectJ may get alot more > attention. > For instance I'm annoyed with the fact that aspectjrt.jar does not have > a valid OSGi manifest. If it was easier for me to setup an AspectJ > development environment I could have created, tested and sent you a patch for > that. And that's the smallest thing. The next thing I would do is to make > declare error/warning conditional on e.g. system properties. I cannot do it > right now because I'm not confident I know enough about the system in order > to do it properly. > What do you think? > > Thanks. > > MP > > > The arithmetic instructions could be surfaced as join points. > e.g. iadd/isub/dadd/lsub/etc. Join points are really just a manifestation of > a bytecode instruction. However, these instructions operate on the stack and > AspectJ does not track who put what on the stack, so in the pointcut/advice > you would be able to receive the operand values but you wouldn't be able to, > for example "match when anything is added to i" because when the join point > is constructed we don't know that 'i' is on the stack. And matching based on > specific values would usually need to be a done with an inserted dynamic > test, because we don't statically know what is on the stack, e.g. "match when > anything has 5 added to it" (possible exceptions could be when low number > constants are used and so the bytecode has one operand encoded in it, e.g. > iadd_1) > > > > > > > > > > > > > > > Implementation: only a few days to get something hanging > together but a lot longer to get it meshing consistently with all the other > language constructs. There would be a need to define what every pointcut > designator means when it hits an arithmetic join point. > > > > > > > > > > > > > > > > > > Adding join points is a serious business though as it can cause > issues for anyone upgrading to new versions of AspectJ. Their older aspects > may suddenly start matching on unintended join points. I think those most > recently added were for array construction and those are still protected with > an option flag to turn them on (for the very reason that old aspects don't > trip over them). > > > > > > > > > > > > > > > > > > As Alexander says, you can be at the mercy of what the compiler > chooses to do in terms of optimization but this isn't anything particularly > new, there are cases of this already here and there. > > > > > > > > > > > > > > > > > > Is it on the roadmap? Not at the moment. We have things like > proper handling of invokedynamic and the incoming Java8 language features to > worry about. > > > > > > > > > > > > > > > cheers, > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On 7 January 2013 03:52, Alexander Kriegisch > > > > > > > wrote: > > > > > > > > > Maybe you should have a look into other bytecode > instrumentation frameworks such as BCEL, if you need to work on such a low > level of granularity. The effort should be justifiedmfor you if you do have a > real world use case and cannot solve it in another way. Good luck! > > > > > > Alexander Kriegisch > > > > > > Am 07.01.2013 um 12:46 schrieb "M. P." < > > > > free...@abv.bg>: > > > > > > > > > > > > >> There is no operator overloading in Java. It is > implemented in other JVM languages like Scala, but this is a bit off-topic > here. > > > > > > > > > > > >> BTW, I did not say it was impossible, just that it will > probably never happen in AspectJ. ;) What you show is normal method > interception, not operator interception. Smthe example is not really > relevant. Besides, you never know what a compiler might do with arithmetic > operations optimisation-wise. Multiplication by powers of 2 might get > replaced by left-shift operations (just making up an example). I do not even > say that what you suggest might not be useful in so e rare and special cases, > I just think it is way to fine-granular for AOP purposes. I think your > example is rather academic than useful in daily work. > > > > > > > > > > > >> Alexander Kriegisch > > > > > > > > > > > >> Am 07.01.2013 um 10:34 schrieb "M. P." : > > > > > > > > > > > >>>>> For example I'd like to be able to select integer > subtraction: > > > > > > > > > > > > > > > >>>>> Integer i = 5; > > > > > > > > > > > >>>>> Integer j = 2; > > > > > > > > > > > >>>>> Integer r = i - j; > > > > > > > > > > > > > > > >>>>> Maybe if Java supported operator overloading that > would be fairly easy. > > > > > > > > > > > > > > > >>>>> 1. So is something like this possible now? I'm pretty > sure it is not. > > > > > > > > > > > > > > > >>>> You are right, it is not possible. > > > > > > > > > > > > > > > >>>>> 2. Would this be possible to implement? How? Effort? > > > > > > > > > > > >>>>> 3. Is something like this planned for future AspectJ > versions? > > > > > > > > > > > > > > > >>>> I cannot speak for the developers, but I do not think > you will ever see this feature in AspectJ. > > > > > > > > > > > > > > > > > > > > > > > >>>> Regards > > > > > > > > > > > > > > > >>> I'm not sure I see why not. Please consider the > following example: > > > > > > > > > > > >>> public aspect StringConcat { > > > > > > > >>> public pointcut concat() : call(* > java.lang.StringBuffer.append(..)); > > > > > > > > > > > >>> before() : concat() { > > > > > > > >>> System.out.println("About to concatenate!"); > > > > > > > >>> } > > > > > > > >>> } > > > > > > > > > > > >>> public class Tester { > > > > > > > > > > > >>> public static void main(String[] args) { > > > > > > > >>> String a = "a"; > > > > > > > >>> String b = "b"; > > > > > > > >>> System.out.println(a + b); > > > > > > > >>> } > > > > > > > >>> } > > > > > > > > > > > >>> When main() is executed the result is: > > > > > > > >>> ======================= > > > > > > > >>> About to concatenate! > > > > > > > >>> ab > > > > > > > >>> ======================= > > > > > > > > > > > >>> So we actually have a real example where the + operator > is overloaded and the resulting code is directly in the client byte code. > > > > > > > >>> Now I'm not too familiar with the Java byte code spec > but I don't see why the same cannot be done for e.g. Integer or event the > primitive types? > > > > > > > > > > > >>> Thank you. > > > > > > > > > > > >>> MP > > > > > > > > > > > > A quick look at the Java byte code format reveals that it > doesn't even have to be done via operator overloading. There is a separate > instruction for each operation. The instruction for method invokation works > similarly to the instruction for integer division so it doesn't seem > problematic to add arithmetic operations as join points. Of course all of > this is just guessing. Perhaps AspectJ developers can clarify a bit? > > > > As to the statement that this example is rather > academic...I could come up with a case where this has a real world value. > > > > Suppose arithmetic join points were supported by AspectJ. > This would make possible for aspects that could prevent overflows. As you > know Java allows silent overflows. What if AspectJ could prevent that? > > > > > > > > Thank you. > > > > MP > > _______________________________________________ > aspectj-users mailing list > > aspectj-users@eclipse.org > > https://dev.eclipse.org/mailman/listinfo/aspectj-users > > > > > > > > _______________________________________________ aspectj-users mailing list aspectj-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/aspectj-users
