Re: [aspectj-users] aspectjrt.jar OSGi manifest
I'm asking because SpringSource Bundlor has been discontinued. The current stuff has been moved to Virgo and will not be a separate package as far as I understand. http://www.springsource.org/bundlor On the other hand BND is not going away any time soon, plus I think it has a bigger community. I have some experience with BND and I know it can generate "uses" directives which are not easy to add manually. Of course it is up to you. AspectJ's bundles are simple enough so it doesn't really matter which tool is used. I'd like to ask you to make this decision then I'll play with the build for a while and will get back to you with either a patch or questions :) Regards M >Hi, > My preference for bundlor was only because I knew the team that wrote it > and could hassle them directly with questions :) but really whatever works is > fine. > There was a nightly build (cruisecontrol driven) running on the eclipse > servers but since we moved from CVS to GIT last year it hasn't been > resurrected - another thing on my todo list ! Right now I tend to do adhoc > dev builds now and again and upload them, in between the full releases (a > 1.7.2 release isn't too far away, it'd be great to get the OSGi manifests > done for that). > cheers, > Andy > On 15 January 2013 23:34, M. P. > wrote: > > > Great. > So as far as I understand you prefer Bundlor over BND? > Now that you mention the build process, is there a periodic build > running? > > Thank you. > > >> Yep, that is ok with me and ideally what I'd like to do. My > hesitancy about it is just because I am aware that the build process is not a > fun place to work at the moment so it may not be as straightforward as you > imagine... > >> > >> > >> > >> > >> Andy > > > > >> > >> > >> > >> > >> > >> On 15 January 2013 02:59, M. P. > > > > > >> wrote: > > > > > > > > > Looks like this is a slight misunderstanding. > > > I meant to use BND or Bundlor in the build script to generate > the manifest every time. And test the resulting OSGi bundle in a real OSGi > runtime just once (manually, before this is committed). > > > Is that OK with you? > > > > > > Thank you. > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'd be ok with a one time manual test to verify it is > basically correct. I previously used bundlor but was not in a position to > verify the output so I never committed it. Ideally I wanted to integrate > bundlor invocation into the build process so that when occasionally a new > package is added or one deleted, the manifest stays in step. Rather than > just run bundlor once and commit those fixed manifests. However, if a 'one > off run' is simplest then I'd be ok to use it for aspectjrt.jar as the > package set for that hardly ever changes. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > cheers, > > > > > > > > > > > > &g
Re: [aspectj-users] aspectjrt.jar OSGi manifest
Great. So as far as I understand you prefer Bundlor over BND? Now that you mention the build process, is there a periodic build running? Thank you. >Yep, that is ok with me and ideally what I'd like to do. My hesitancy > about it is just because I am aware that the build process is not a fun place > to work at the moment so it may not be as straightforward as you imagine... > > > > > Andy > > > > > > > On 15 January 2013 02:59, M. P. > wrote: > > > Looks like this is a slight misunderstanding. > I meant to use BND or Bundlor in the build script to generate the > manifest every time. And test the resulting OSGi bundle in a real OSGi > runtime just once (manually, before this is committed). > Is that OK with you? > > Thank you. > > >> Hi, > >> > >> > >> > >> > >> I'd be ok with a one time manual test to verify it is basically > correct. I previously used bundlor but was not in a position to verify the > output so I never committed it. Ideally I wanted to integrate bundlor > invocation into the build process so that when occasionally a new package is > added or one deleted, the manifest stays in step. Rather than just run > bundlor once and commit those fixed manifests. However, if a 'one off run' is > simplest then I'd be ok to use it for aspectjrt.jar as the package set for > that hardly ever changes. > >> > >> > >> > >> > >> > >> cheers, > >> > >> > >> Andy > >> > >> > >> > >> > >> > >> On 11 January 2013 11:11, M. P. > > > > > >> wrote: > > > > > > > > > > > > > I'd assume they have an environment in which to verify the > correctness of what is being created. > > > > > > > > > Do mean an automatic test suite or one-time manual testing? > > > > > > Automatic tests would be very nice but they would require > serious machinery such as the OSGi runtime. > > > And maybe these bundles (aspectrt, weaver, etc) are simple > enough so that it is safe to assume that tools such as BND and Bundlor > generate valid manifests? > > > > > > What do you think? > > > > > > Thanks. > > > > > > > > > > > > > > > > The weaver also needs one (and I suppose it does no > harm to get it right for tools and matcher too). > > > > > > > > > > > > > > > > > > > > > This has long been on the list of TODOs (see bugs > like > > > > > > > > > > >https://bugs.eclipse.org/bugs/show_bug.cgi?id=338034) - I even > prototyped the implementation with bundlor ( > > > > > > > > > > >http://www.springsource.org/bundlor). I created some basic versions > for testing but I don't believe the users got back to me about whether what > was being generated was correct. Traditionally users just seemed to go the > EBR and collect the versions from there which had had their manifests > regenerated. I'd be happy for someone to take this on and sort it out > properly for AspectJ, I'm more than ha
Re: [aspectj-users] aspectjrt.jar OSGi manifest
Looks like this is a slight misunderstanding. I meant to use BND or Bundlor in the build script to generate the manifest every time. And test the resulting OSGi bundle in a real OSGi runtime just once (manually, before this is committed). Is that OK with you? Thank you. >Hi, > > > > > I'd be ok with a one time manual test to verify it is basically correct. > I previously used bundlor but was not in a position to verify the output so I > never committed it. Ideally I wanted to integrate bundlor invocation into the > build process so that when occasionally a new package is added or one > deleted, the manifest stays in step. Rather than just run bundlor once and > commit those fixed manifests. However, if a 'one off run' is simplest then > I'd be ok to use it for aspectjrt.jar as the package set for that hardly ever > changes. > > > > > > cheers, > > > Andy > > > > > > On 11 January 2013 11:11, M. P. > wrote: > > > >> I'd assume they have an environment in which to verify the > correctness of what is being created. > > > Do mean an automatic test suite or one-time manual testing? > >Automatic tests would be very nice but they would require serious > machinery such as the OSGi runtime. >And maybe these bundles (aspectrt, weaver, etc) are simple enough so > that it is safe to assume that tools such as BND and Bundlor generate valid > manifests? > >What do you think? > >Thanks. > > > > > > The weaver also needs one (and I suppose it does no harm to get > it right for tools and matcher too). > > > > > > > > > This has long been on the list of TODOs (see bugs like > > > >https://bugs.eclipse.org/bugs/show_bug.cgi?id=338034) - I even > prototyped the implementation with bundlor ( > > > >http://www.springsource.org/bundlor). I created some basic versions > for testing but I don't believe the users got back to me about whether what > was being generated was correct. Traditionally users just seemed to go the > EBR and collect the versions from there which had had their manifests > regenerated. I'd be happy for someone to take this on and sort it out > properly for AspectJ, I'm more than happy to help them progress it - I'd > assume they have an environment in which to verify the correctness of what is > being created. > > > > > > > > > The AspectJ build process is a bit arcane, which can make > something you'd think would be easy, rather tricky, but I'll help a brave > soul battle through that. > > > > > > > > > cheers, > > > > > > Andy > > > > On 10 January 2013 06:51, M. P. > > > > > > > wrote: > > > > > >> The aspectjrt.jar does not have a valid OSGi manifest at the > moemnt. It would be nice if it did. > > >> In order to make it OSGi compliant the manifest should get > a few more headers such as Export-Package. > > >> I saw that the aspectjrt.jar manifest is generated from > this file > > >> > > http://git.eclipse.org/c/aspectj/org.aspectj.git/tree/aspectj5rt/aspectj5rt.mf.txt > > >> Since the packages listed in Export-Package should have > versions adding this header to the manifest template is problemat because > when the version placeholders are replaced with the real values the format of > the manifest may become invalid. > > >> So how do you feel about generating the manifest in the > build script via > > >> > http://ant.apache.org/manual/Tasks/manifest.html? > > >> > > >> Thanks. > &
Re: [aspectj-users] aspectjrt.jar OSGi manifest
> I'd assume they have an environment in which to verify the correctness of > what is being created. Do mean an automatic test suite or one-time manual testing? Automatic tests would be very nice but they would require serious machinery such as the OSGi runtime. And maybe these bundles (aspectrt, weaver, etc) are simple enough so that it is safe to assume that tools such as BND and Bundlor generate valid manifests? What do you think? Thanks. >The weaver also needs one (and I suppose it does no harm to get it right > for tools and matcher too). > > > This has long been on the list of TODOs (see bugs like > https://bugs.eclipse.org/bugs/show_bug.cgi?id=338034) - I even prototyped > the implementation with bundlor ( > http://www.springsource.org/bundlor). I created some basic versions for > testing but I don't believe the users got back to me about whether what was > being generated was correct. Traditionally users just seemed to go the EBR > and collect the versions from there which had had their manifests > regenerated. I'd be happy for someone to take this on and sort it out > properly for AspectJ, I'm more than happy to help them progress it - I'd > assume they have an environment in which to verify the correctness of what is > being created. > > > The AspectJ build process is a bit arcane, which can make something you'd > think would be easy, rather tricky, but I'll help a brave soul battle through > that. > > > cheers, > > Andy > On 10 January 2013 06:51, M. P. > wrote: > >> The aspectjrt.jar does not have a valid OSGi manifest at the moemnt. It >> would be nice if it did. >> In order to make it OSGi compliant the manifest should get a few more >> headers such as Export-Package. >> I saw that the aspectjrt.jar manifest is generated from this file >> >> http://git.eclipse.org/c/aspectj/org.aspectj.git/tree/aspectj5rt/aspectj5rt.mf.txt >> Since the packages listed in Export-Package should have versions >> adding this header to the manifest template is problemat because when the >> version placeholders are replaced with the real values the format of the >> manifest may become invalid. >> So how do you feel about generating the manifest in the build script >> via >> http://ant.apache.org/manual/Tasks/manifest.html? >> >> Thanks. >> ___ >> 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] aspectjrt.jar OSGi manifest
The aspectjrt.jar does not have a valid OSGi manifest at the moemnt. It would be nice if it did. In order to make it OSGi compliant the manifest should get a few more headers such as Export-Package. I saw that the aspectjrt.jar manifest is generated from this file http://git.eclipse.org/c/aspectj/org.aspectj.git/tree/aspectj5rt/aspectj5rt.mf.txt Since the packages listed in Export-Package should have versions adding this header to the manifest template is problemat because when the version placeholders are replaced with the real values the format of the manifest may become invalid. So how do you feel about generating the manifest in the build script via http://ant.apache.org/manual/Tasks/manifest.html? Thanks. ___ 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?
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 p
Re: [aspectj-users] Selecting arithmetic operation join points. Is it possible?
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
Re: [aspectj-users] Selecting arithmetic operation join points. Is it possible?
> 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?
> > 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] Selecting arithmetic operation join points. Is it possible?
Hi, The subject pretty much says it all. 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. 2. Would this be possible to implement? How? Effort? 3. Is something like this planned for future AspectJ versions? Thank you. MP ___ aspectj-users mailing list aspectj-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/aspectj-users
