Re: [aspectj-users] Selecting arithmetic operation join points. Is it possible?

2013-01-10 Thread M. P.
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 
 

Re: [aspectj-users] Selecting arithmetic operation join points. Is it possible?

2013-01-08 Thread M. P.
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:
 
 
 
 
 
 
 
  

Re: [aspectj-users] Selecting arithmetic operation join points. Is it possible?

2013-01-08 Thread Andy Clement
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:buildingsourceyou
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. free...@abv.bg 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 

Re: [aspectj-users] Selecting arithmetic operation join points. Is it possible?

2013-01-07 Thread Alexander Kriegisch

 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
--
Alexander Kriegisch
http://scrum-master.de
___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users


Re: [aspectj-users] Selecting arithmetic operation join points. Is it possible?

2013-01-07 Thread 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
___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users


Re: [aspectj-users] Selecting arithmetic operation join points. Is it possible?

2013-01-07 Thread Alexander Kriegisch
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. free...@abv.bg:

 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
 ___
 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


Re: [aspectj-users] Selecting arithmetic operation join points. Is it possible?

2013-01-07 Thread M. P.
 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


Re: [aspectj-users] Selecting arithmetic operation join points. Is it possible?

2013-01-07 Thread Alexander Kriegisch
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


Re: [aspectj-users] Selecting arithmetic operation join points. Is it possible?

2013-01-07 Thread Andy Clement
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 alexan...@kriegisch.namewrote:

 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