Ok, I just tried it and it worked for me, I was using a recent dev
build.  I then upgraded again just to make sure it still worked on the
latest and it does (3.7 dev stream).  I compiled this program and ran
it:

===
import java.lang.reflect.Field;
import java.lang.reflect.Modifier;


public class Foo {
       public static void main(String[] args) throws Exception {
               Foo foo = new Foo();
               foo.a();
               foo.b();
               foo.c();
               Field[] fs = Foo.class.getDeclaredFields();
               for (Field f: fs) {
                       if (f.getName().startsWith("ajc$")) {
                               System.out.println(f+" transient?"+Modifier.isTransient(f.getModifiers()));
                       }
               }
       }

       public void a() {       }
       public void b() {       }
       public void c() {       }
}

aspect Advisor {
       before(): execution(* Foo.*(..)) {
               System.out.println(thisJoinPointStaticPart);
       }
}

With the option set it prints:

execution(void Foo.main(String[]))
execution(void Foo.a())
execution(void Foo.b())
execution(void Foo.c())
private static final transient org.aspectj.lang.JoinPoint$StaticPart
Foo.ajc$tjp_0 transient?true
private static final transient org.aspectj.lang.JoinPoint$StaticPart
Foo.ajc$tjp_1 transient?true
private static final transient org.aspectj.lang.JoinPoint$StaticPart
Foo.ajc$tjp_2 transient?true
private static final transient org.aspectj.lang.JoinPoint$StaticPart
Foo.ajc$tjp_3 transient?true


The option being -Xset:makeTjpFieldsTransient=true, and I set that in
the project properties "AspectJ Compiler" > Other > "Non-standard
compiler options"

How were you trying it? (taking jars from an AJ and dropping them into
an AJDT doesn't work very well as the packaging is different in AJDT)

cheers,
Andy

On 12 April 2012 06:39, Choudary Kothapalli

<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

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

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

I'm afraid you are at the mercy of the import operation that was used
to move the CVS repo to GIT - (which I think was git-cvsimport -i -p
-x).

After the webmaster ran it, I noticed mistakes in the git repo and had
to just patch them up manually and move on.  I've not had much reason
to go back and checkout older versions recently, so don't know how
damaged things are in the past.

> Some files are changed added removed copied or renamed. Thus, If i take the
> snapshot of the repository at revID-1 and combine that info with the changes
> made in revision revID, then the snapshot at revID of the repository
> calculated in this way should be consistent with an independently captured
> snapshot of the repository at revID. Am I correct?

that seems a reasonable expectation to me.

Andy

On 9 April 2012 14:04, Shivani Rao <raoshivani@xxxxxxxxx> wrote:
> Hello,
>
> I am noticing a ton of discrepancies in the  git eclipse aspectj repository.
> I am mining this repository for mining purposes.
> Of all the error this one is beyond my capacity to fix.
>
> Some files are changed added removed copied or renamed. Thus, If i take the
> snapshot of the repository at revID-1 and combine that info with the changes
> made in revision revID, then the snapshot at revID of the repository
> calculated in this way should be consistent with an independently captured
> snapshot of the repository at revID. Am I correct?
>
> Well, this is not the case of ASPECT. Some files are deleted in earlier
> revisions but magically re-appear in the snapshot at a later time.
>
> Has anybody else encountered this? What is the workaround?
>
> Shivani
>
> --
> Research Scholar,
> School of Electrical and Computer Engineering
> Purdue University
> West Lafayette IN
> web.ics.purdue.edu/~sgrao
>

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