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.name>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
>
_______________________________________________
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
