<
choudary.kothapalli@xxxxxxxxx> wrote:
> Yes, I have tried, but it does not seem to work. I am using AJDT to compile.
> I replaced the original aspectjrt.jar and aspectjweaver.jar with the ones
> from your dev build.
>
> Is there a corresponding AJDT dev build that I can try with?
>
> Thanks,
> Choudary.
>
>
> On Wed, Apr 11, 2012 at 8:46 PM, Andy Clement <
andrew.clement@xxxxxxxxx>
> wrote:
>>
>> Hi,
>>
>> As it was added as an -Xset option, it should just work for compile
>> time weaving too. Have you tried it?
>>
>> cheers
>> Andy
>>
>> On 11 April 2012 15:45, Choudary Kothapalli
>> <
choudary.kothapalli@xxxxxxxxx> wrote:
>> > Andy,
>> >
>> > You added an option to make the synthetic JoinPointImpl$StaticPartImpl
>> > fields transient for load time weaved classes and it's working fine. Can
>> > the
>> > same thing be done for compile time weaved classes too? I mean, can you
>> > add
>> > an option to the compile time weaver so that the
>> > JoinPointImpl$StaticPartImpl fields are marked transient?
>> >
>> > Thanks,
>> > Choudary Kothapalli.
>> >
>> >
>> > On Fri, Mar 2, 2012 at 2:02 PM, Andy Clement <
andrew.clement@xxxxxxxxx>
>> > wrote:
>> >>
>> >> I checked the code and suid calculations ignore private static and
>> >> private transient fields. So even right now the SUIDs will be the
>> >> same for a class with/without these (as they are private static)
>> >>
>> >> if you raise an issue about making them transient, I'll have a look at
>> >> doing it.
>> >>
>> >> cheers,
>> >> Andy
>> >>
>> >> On 2 March 2012 10:43, Choudary Kothapalli
>> >> <
choudary.kothapalli@xxxxxxxxx> wrote:
>> >> > Yes, that seems to be the cleaner solution.
>> >> >
>> >> > 1. When the load time woven classes are involved in both serializing
>> >> > and
>> >> > deserializing: The transient fields are not serialized and when the
>> >> > during
>> >> > deserialization these fields are initialized in ajc$preClinit().
>> >> >
>> >> > 2. When serialized by a woven class and deserialized by a regular
>> >> > class:
>> >> > What will happen if SUID is not defined in the class? Wouldn't the
>> >> > generated
>> >> > SUID's be different?
>> >> >
>> >> > 3. When serialized by a regular class and deserialized by a woven
>> >> > class:
>> >> > Again, would the SUID's match if they are not already defined?
>> >> >
>> >> > My problem is more of scenario 1 and it should be solved by making
>> >> > the
>> >> > synthetic fields transient.
>> >> >
>> >> > Thanks,
>> >> > Choudary.
>> >> >
>> >> >
>> >> > On Fri, Mar 2, 2012 at 1:28 PM, Andy Clement
>> >> > <
andrew.clement@xxxxxxxxx>
>> >> > wrote:
>> >> >>
>> >> >> Sorry, I was just saying that if you need to reinitialize those
>> >> >> fields
>> >> >> at any time then that is the method you need to call, but yes the
>> >> >> clinit for the class sets them up the first time. Are we back to
>> >> >> just
>> >> >> considering transient as a suitable fix for your situation then?
>> >> >>
>> >> >> Andy
>> >> >>
>> >> >> On 2 March 2012 09:57, Choudary Kothapalli
>> >> >> <
choudary.kothapalli@xxxxxxxxx> wrote:
>> >> >> > I am checking the decompiled version of a load time woven class
>> >> >> > and
>> >> >> > this
>> >> >> > is
>> >> >> > what I see.
>> >> >> >
>> >> >> > The ajc$preClinit() seems to the place where the 'ajc$tjp_x'
>> >> >> > fields
>> >> >> > are
>> >> >> > initialized. The ajc$preClinit() is called in a static block as
>> >> >> > below:
>> >> >> >
>> >> >> > static {
>> >> >> > ajc$preClinit();
>> >> >> > }
>> >> >> >
>> >> >> > If this is the case, why do you say that it should be called just
>> >> >> > after
>> >> >> > deserialization? Wouldn't it be called as soon as the class is
>> >> >> > loaded
>> >> >> > anyway?
>> >> >> >
>> >> >> > Thanks,
>> >> >> > Choudary.
>> >> >> >
>> >> >> >
>> >> >> > On Fri, Mar 2, 2012 at 11:07 AM, Andy Clement
>> >> >> > <
andrew.clement@xxxxxxxxx>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> I think all the fields mentioned that aren't basic strings are
>> >> >> >> populated 'on-demand' based on the string data (or other factors
>> >> >> >> that
>> >> >> >> don't need serializing). That includes method/class fields and
>> >> >> >> the
>> >> >> >> Cache field you mention - so making those transient is fine.
>> >> >> >>
>> >> >> >> As John points out you will have incompatibilities between
>> >> >> >> weaved/unweaved if the fields are included in the serialized
>> >> >> >> object.
>> >> >> >> Interestingly this is not a new problem, and I have no bugzillas
>> >> >> >> relating to it being an issue so I guess it really doesn't come
>> >> >> >> up
>> >> >> >> very often.
>> >> >> >>
>> >> >> >> If you want to rebuild the values for the fields, the target
>> >> >> >> types
>> >> >> >> containing them should all have a method in like this:
>> >> >> >>
>> >> >> >> private static void ajc$preClinit();
>> >> >> >>
>> >> >> >> which you could invoke to do so. But you'd have to ensure it
>> >> >> >> gets
>> >> >> >> called just after deserialization. I would need to check what
>> >> >> >> else
>> >> >> >> ajc$preClinit() might do but I'm pretty sure it is just those tjp
>> >> >> >> values.
>> >> >> >>
>> >> >> >> I can see arguments both ways: making tjp fields transient and
>> >> >> >> calling
>> >> >> >> ajc$preClinit or making them serializable if it is tricky to get
>> >> >> >> ajc$preClinit called at the right time. If compile time weaving
>> >> >> >> it
>> >> >> >> doesn't seem as much of an issue for incompatibility between
>> >> >> >> weaved/unweaved form because the unweaved form is gone. With ltw
>> >> >> >> maybe there is more chance of encountering the unwoven form again
>> >> >> >> sometime later.
>> >> >> >>
>> >> >> >> Andy
>> >> >> >>
>> >> >> >> On 2 March 2012 07:34, Choudary Kothapalli
>> >> >> >> <
choudary.kothapalli@xxxxxxxxx> wrote:
>> >> >> >> >>>Would it be possible to have these fields set to transient but
>> >> >> >> >>> set
>> >> >> >> >>> them
>> >> >> >> >>> on-demand when deserialized (one time only) ?
>> >> >> >> >
>> >> >> >> > If you are talking about the following field, Andy may be the
>> >> >> >> > better
>> >> >> >> > person
>> >> >> >> > to answer. It looks possible to me and it might be the
>> >> >> >> > cleanest
>> >> >> >> > solution to
>> >> >> >> > this problem.
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > private static final org.aspectj.lang.JoinPoint.StaticPart
>> >> >> >> > ajc$tjp_0;
>> >> >> >> > /*
>> >> >> >> > synthetic field */
>> >> >> >> >
>> >> >> >> >>>Choudary, does your product require transparency in
>> >> >> >> >>> deserializing
>> >> >> >> >>> the
>> >> >> >> >>> instrumented objects (from an uninstrumented instance of the
>> >> >> >> >>> application)?
>> >> >> >> >
>> >> >> >> > At least my current problem involves using the same
>> >> >> >> > instrumented
>> >> >> >> > classes
>> >> >> >> > while serializing and deserializing. I didn't really think of
>> >> >> >> > the
>> >> >> >> > scenario
>> >> >> >> > of needing to deserialize using the uninstrumented classes,
>> >> >> >> > which
>> >> >> >> > might
>> >> >> >> > occur.
>> >> >> >> >
>> >> >> >> > So I think it would be a better idea to make the
>> >> >> >> > 'JoinPoint.StaticPart
>> >> >> >> > ajc$tjp_0;' fields transient and to set them on demand, if it's
>> >> >> >> > possible
>> >> >> >> > to
>> >> >> >> > do so.
>> >> >> >> >
>> >> >> >> > Thanks,
>> >> >> >> > Choudary.
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On Fri, Mar 2, 2012 at 9:58 AM, John Kew <
jkew@xxxxxxxxxx>
>> >> >> >> > wrote:
>> >> >> >> >>
>> >> >> >> >> If I understand the use-case/problem correctly, there are not
>> >> >> >> >> many
>> >> >> >> >> great
>> >> >> >> >> solutions to this problem.
>> >> >> >> >>
>> >> >> >> >> Either we serialize StaticPart along with the object and make
>> >> >> >> >> the
>> >> >> >> >> serialized class incompatible with an unweaved application, or
>> >> >> >> >> we
>> >> >> >> >> make
>> >> >> >> >> it
>> >> >> >> >> transient and risk an inconsistent or unexpected state after
>> >> >> >> >> the
>> >> >> >> >> object
>> >> >> >> >> is
>> >> >> >> >> rehydrated.
>> >> >> >> >>
>> >> >> >> >> Would it be possible to have these fields set to transient but
>> >> >> >> >> set
>> >> >> >> >> them
>> >> >> >> >> on-demand when deserialized (one time only) ? Choudary, does
>> >> >> >> >> your
>> >> >> >> >> product
>> >> >> >> >> require transparency in deserializing the instrumented objects
>> >> >> >> >> (from
>> >> >> >> >> an
>> >> >> >> >> uninstrumented instance of the application)?
>> >> >> >> >>
>> >> >> >> >> -John
>> >> >> >> >>
>> >> >> >> >> ________________________________
>> >> >> >> >> From: "Choudary Kothapalli" <
choudary.kothapalli@xxxxxxxxx>
>> >> >> >> >> To: "AspectJ developer discussions" <
aspectj-dev@xxxxxxxxxxx>
>> >> >> >> >> Sent: Friday, March 2, 2012 6:22:38 AM
>> >> >> >> >> Subject: Re: [aspectj-dev]
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> NotSerializableException: org.aspectj.runtime.reflect.JoinPointImpl$StaticPartImpl
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> Hi Andy,
>> >> >> >> >>
>> >> >> >> >> I will try to give you the patch, but here is what I notice
>> >> >> >> >> after
>> >> >> >> >> taking a
>> >> >> >> >> deeper look into the JoinPointImpl.StaticPartImpl class.
>> >> >> >> >>
>> >> >> >> >> Not all fields in this class are primitives and Serializable
>> >> >> >> >> classes.
>> >> >> >> >> For
>> >> >> >> >> example, the Signature implementation classes like
>> >> >> >> >> AdviceSignatureImpl
>> >> >> >> >> have
>> >> >> >> >> Method as a field, which is not Serializable. But I think we
>> >> >> >> >> can
>> >> >> >> >> safely
>> >> >> >> >> make
>> >> >> >> >> this a transient field.
>> >> >> >> >>
>> >> >> >> >> The same applies to Cache field in the SignatureImpl class. I
>> >> >> >> >> think
>> >> >> >> >> we
>> >> >> >> >> can
>> >> >> >> >> make it transient too.
>> >> >> >> >>
>> >> >> >> >> Shall I go ahead and do these changes or do you have any
>> >> >> >> >> reservations?
>> >> >> >> >>
>> >> >> >> >> Thanks,
>> >> >> >> >> Choudary.
>> >> >> >> >>
>> >> >> >> >> On Thu, Mar 1, 2012 at 11:05 AM, Andy Clement
>> >> >> >> >> <
andrew.clement@xxxxxxxxx>
>> >> >> >> >> wrote:
>> >> >> >> >>>
>> >> >> >> >>> Sure, and if you want to give me a patch that does it, even
>> >> >> >> >>> better
>> >> >> >> >>> :)
>> >> >> >> >>>
>> >> >> >> >>> cheers,
>> >> >> >> >>> Andy
>> >> >> >> >>>
>> >> >> >> >>> On 29 February 2012 16:52, Choudary Kothapalli
>> >> >> >> >>> <
choudary.kothapalli@xxxxxxxxx> wrote:
>> >> >> >> >>> > Shall I raise a request to make JoinPoint.StaticPart
>> >> >> >> >>> > serializable,
>> >> >> >> >>> > then? It
>> >> >> >> >>> > would solve the problem of serialization.
>> >> >> >> >>> >
>> >> >> >> >>> > Choudary.
>> >> >> >> >>> >
>> >> >> >> >>> >
>> >> >> >> >>> > On Wed, Feb 29, 2012 at 6:03 PM, Andy Clement
>> >> >> >> >>> > <
andrew.clement@xxxxxxxxx>
>> >> >> >> >>> > wrote:
>> >> >> >> >>> >>
>> >> >> >> >>> >> Making them serializable is also reasonable. There is
>> >> >> >> >>> >> nothing
>> >> >> >> >>> >> special
>> >> >> >> >>> >> in them - mostly strings/ints.
>> >> >> >> >>> >>
>> >> >> >> >>> >> There is no option to weave the classes with no synthetic
>> >> >> >> >>> >> fields.
>> >> >> >> >>> >> It
>> >> >> >> >>> >> is feasible but they aren't necessarily cheap to construct
>> >> >> >> >>> >> and
>> >> >> >> >>> >> inlining their construction where they are used would
>> >> >> >> >>> >> damage
>> >> >> >> >>> >> performance to some degree.
>> >> >> >> >>> >>
>> >> >> >> >>> >> Andy
>> >> >> >> >>> >>
>> >> >> >> >>> >> On 29 February 2012 14:12, Choudary Kothapalli
>> >> >> >> >>> >> <
choudary.kothapalli@xxxxxxxxx> wrote:
>> >> >> >> >>> >> > On second thoughts, making them transient may not be a
>> >> >> >> >>> >> > good
>> >> >> >> >>> >> > idea
>> >> >> >> >>> >> > because
>> >> >> >> >>> >> > the
>> >> >> >> >>> >> > deserialization may fail.
>> >> >> >> >>> >> >
>> >> >> >> >>> >> > Do you think you can make JoinPoint.StaticPart and its
>> >> >> >> >>> >> > contents
>> >> >> >> >>> >> > Serializable? I am not sure if that would be correct,
>> >> >> >> >>> >> > but
>> >> >> >> >>> >> > just
>> >> >> >> >>> >> > asking.
>> >> >> >> >>> >> >
>> >> >> >> >>> >> > Or, is there any option to weave the classes so that the
>> >> >> >> >>> >> > synthetic
>> >> >> >> >>> >> > fields do
>> >> >> >> >>> >> > not exist at all?
>> >> >> >> >>> >> >
>> >> >> >> >>> >> > I know that I'm asking for something that may not be a
>> >> >> >> >>> >> > requirement
>> >> >> >> >>> >> > for
>> >> >> >> >>> >> > most
>> >> >> >> >>> >> > usage scenarios or the actual intended usage of AspectJ.
>> >> >> >> >>> >> > But I
>> >> >> >> >>> >> > am
>> >> >> >> >>> >> > stuck
>> >> >> >> >>> >> > with
>> >> >> >> >>> >> > this problem and just checking if there is a way out.
>> >> >> >> >>> >> >
>> >> >> >> >>> >> > Thanks for your time.
>> >> >> >> >>> >> >
>> >> >> >> >>> >> > Choudary.
>> >> >> >> >>> >> >
>> >> >> >> >>> >> >
>> >> >> >> >>> >> > On Wed, Feb 29, 2012 at 4:39 PM, Andy Clement
>> >> >> >> >>> >> > <
andrew.clement@xxxxxxxxx>
>> >> >> >> >>> >> > wrote:
>> >> >> >> >>> >> >>
>> >> >> >> >>> >> >> I can provide you an option to make them transient, but
>> >> >> >> >>> >> >> I'm
>> >> >> >> >>> >> >> hesitant
>> >> >> >> >>> >> >> to just change the default to transient. If you want
>> >> >> >> >>> >> >> an
>> >> >> >> >>> >> >> option
>> >> >> >> >>> >> >> like
>> >> >> >> >>> >> >> that, please open a bugzilla:
>> >> >> >> >>> >> >>
>> >> >> >> >>> >> >>
>> >> >> >> >>> >> >>
https://bugs.eclipse.org/bugs/enter_bug.cgi?product=AspectJ
>> >> >> >> >>> >> >>
>> >> >> >> >>> >> >> and I'll take a look.
>> >> >> >> >>> >> >>
>> >> >> >> >>> >> >> cheers,
>> >> >> >> >>> >> >> Andy
>> >> >> >> >>> >> >>
>> >> >> >> >>> >> >> On 28 February 2012 14:35, Choudary Kothapalli
>> >> >> >> >>> >> >> <
choudary.kothapalli@xxxxxxxxx> wrote:
>> >> >> >> >>> >> >> > My product MaintainJ uses AspectJ load time weaving
>> >> >> >> >>> >> >> > to
>> >> >> >> >>> >> >> > capture
>> >> >> >> >>> >> >> > the
>> >> >> >> >>> >> >> > call
>> >> >> >> >>> >> >> > trace at runtime. When weaving an application, the
>> >> >> >> >>> >> >> > following
>> >> >> >> >>> >> >> > exception
>> >> >> >> >>> >> >> > is
>> >> >> >> >>> >> >> > seen.
>> >> >> >> >>> >> >> >
>> >> >> >> >>> >> >> > Caused by: java.io.NotSerializableException:
>> >> >> >> >>> >> >> >
>> >> >> >> >>> >> >> > org.aspectj.runtime.reflect.JoinPointImpl$StaticPartImpl
>> >> >> >> >>> >> >> > at
>> >> >> >> >>> >> >> > java.io.ObjectOutputStream.writeObject0(Unknown
>> >> >> >> >>> >> >> > Source)
>> >> >> >> >>> >> >> > at java.io.ObjectOutputStream.writeObject(Unknown
>> >> >> >> >>> >> >> > Source)
>> >> >> >> >>> >> >> > at
>> >> >> >> >>> >> >> >
>> >> >> >> >>> >> >> >
>> >> >> >> >>> >> >> >
>> >> >> >> >>> >> >> > xxx.yyyyy.ZZZClass.writeExternal_aroundBody4(ZZZClass.java:70)
>> >> >> >> >>> >> >> >
>> >> >> >> >>> >> >> > AspectJ LTW seems to insert many fields as below in
>> >> >> >> >>> >> >> > the
>> >> >> >> >>> >> >> > class
>> >> >> >> >>> >> >> > files
>> >> >> >> >>> >> >> > and
>> >> >> >> >>> >> >> > serializing them seems to be failing.
>> >> >> >> >>> >> >> >
>> >> >> >> >>> >> >> > private static final
>> >> >> >> >>> >> >> > org.aspectj.lang.JoinPoint.StaticPart
>> >> >> >> >>> >> >> > ajc$tjp_0;
>> >> >> >> >>> >> >> > /*
>> >> >> >> >>> >> >> > synthetic field */
>> >> >> >> >>> >> >> >
>> >> >> >> >>> >> >> > Is there any quick fix for this? Can AspectJ make
>> >> >> >> >>> >> >> > these
>> >> >> >> >>> >> >> > fields
>> >> >> >> >>> >> >> > transient
>> >> >> >> >>> >> >> > without any other issues?
>> >> >> >> >>> >> >> >
>> >> >> >> >>> >> >> > Thanks,
>> >> >> >> >>> >> >> > Choudary Kothapalli
>> >> >> >> >>> >> >> > MaintainJ Inc.
>> >> >> >> >>> >> >> >
>> >> >> >> >>> >> >> > _______________________________________________
>> >> >> >> >>> >> >> > aspectj-dev mailing list
>> >> >> >> >>> >> >> >
aspectj-dev@xxxxxxxxxxx
>> >> >> >> >>> >> >> >
https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>> >> >> >> >>> >> >> >
>> >> >> >> >>> >> >> _______________________________________________
>> >> >> >> >>> >> >> aspectj-dev mailing list
>> >> >> >> >>> >> >>
aspectj-dev@xxxxxxxxxxx
>> >> >> >> >>> >> >>
https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>> >> >> >> >>> >> >
>> >> >> >> >>> >> >
>> >> >> >> >>> >> >
>> >> >> >> >>> >> > _______________________________________________
>> >> >> >> >>> >> > aspectj-dev mailing list
>> >> >> >> >>> >> >
aspectj-dev@xxxxxxxxxxx
>> >> >> >> >>> >> >
https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>> >> >> >> >>> >> >
>> >> >> >> >>> >> _______________________________________________
>> >> >> >> >>> >> aspectj-dev mailing list
>> >> >> >> >>> >>
aspectj-dev@xxxxxxxxxxx
>> >> >> >> >>> >>
https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>> >> >> >> >>> >
>> >> >> >> >>> >
>> >> >> >> >>> >
>> >> >> >> >>> > _______________________________________________
>> >> >> >> >>> > aspectj-dev mailing list
>> >> >> >> >>> >
aspectj-dev@xxxxxxxxxxx
>> >> >> >> >>> >
https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>> >> >> >> >>> >
>> >> >> >> >>> _______________________________________________
>> >> >> >> >>> aspectj-dev mailing list
>> >> >> >> >>>
aspectj-dev@xxxxxxxxxxx
>> >> >> >> >>>
https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> _______________________________________________
>> >> >> >> >> aspectj-dev mailing list
>> >> >> >> >>
aspectj-dev@xxxxxxxxxxx
>> >> >> >> >>
https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> _______________________________________________
>> >> >> >> >> aspectj-dev mailing list
>> >> >> >> >>
aspectj-dev@xxxxxxxxxxx
>> >> >> >> >>
https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>> >> >> >> >>
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > _______________________________________________
>> >> >> >> > aspectj-dev mailing list
>> >> >> >> >
aspectj-dev@xxxxxxxxxxx
>> >> >> >> >
https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>> >> >> >> >
>> >> >> >> _______________________________________________
>> >> >> >> aspectj-dev mailing list
>> >> >> >>
aspectj-dev@xxxxxxxxxxx
>> >> >> >>
https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > _______________________________________________
>> >> >> > aspectj-dev mailing list
>> >> >> >
aspectj-dev@xxxxxxxxxxx
>> >> >> >
https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>> >> >> >
>> >> >> _______________________________________________
>> >> >> aspectj-dev mailing list
>> >> >>
aspectj-dev@xxxxxxxxxxx
>> >> >>
https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > aspectj-dev mailing list
>> >> >
aspectj-dev@xxxxxxxxxxx
>> >> >
https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>> >> >
>> >> _______________________________________________
>> >> aspectj-dev mailing list
>> >>
aspectj-dev@xxxxxxxxxxx
>> >>
https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>> >
>> >
>> >
>> > _______________________________________________
>> > aspectj-dev mailing list
>> >
aspectj-dev@xxxxxxxxxxx
>> >
https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>> >
>> _______________________________________________
>> aspectj-dev mailing list
>>
aspectj-dev@xxxxxxxxxxx
>>
https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>
>
>
> _______________________________________________
> aspectj-dev mailing list
>
aspectj-dev@xxxxxxxxxxx
>
https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>
_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-dev