Re: [aspectj-users] Two aspects ITDing the same field onto a target typ

[Andy Clement <andrew.clement@xxxxxxxxx>]

Just a quick follow up on this.  AspectJ dev builds will now avoid
mangling private itds onto a target class.  The semantics of ITDs are
completely unchanged, I've only changed how the end result manifests
in the bytecode.  So this ITD:

private int SomeType.foo;

will result in the field 'private int foo' in SomeType (if you attempt
to look at it via reflection or javap).  This is different to how
AspectJ 1.6.8 and previous versions would apply that ITD, where it
would have manifested as 'public int ajc$<declaringaspect>$foo'.

With this change there should be no need to add seemingly unnecessary
annotations to the ITDs that inform underlying persistence code what
the field name actually is.

To support this I have had to change the serialized form for aspects -
which means once this change gets into the tools then users will need
to update any backend AspectJ processing they do with a version of
AspectJ that is at least as up to date as the one in AJDT. So  I won't
be putting this version into AJDT until I have the AJ dev builds
easily accessible in a maven repo.  However, if you want to play with
it now, please download an AspectJ dev build and try it out.

cheers,
Andy

2010/1/21 David Whittaker <dave@xxxxxxxxxx>:
> Hi Andy,
> As someone who has made a lot of use of ITDs, including aspect libraries
> that I use on multiple projects, I don't see many scenarios where a name
> clash would occur, and on the rare occasion where it did happen I would have
> no problem refactoring.  Just my two cents.
> Dave Whittaker
> Iradix, LLC
> (p) 212.513.0874 x100
> (f) 212.504.8213
> dave@xxxxxxxxxx
>
>
> On Thu, Jan 21, 2010 at 4:10 PM, Olle Hallin <olle.hallin@xxxxxx> wrote:
>>
>> But do people really know (or care) what ITDs aspect libraries contain?
>> Or are pehaps aspect libraries not used very much?
>> Olle
>> Olle Hallin
>> Senior Java Developer and Architect
>> olle.hallin@xxxxxxxx
>> www.crisp.se
>> http://www.linkedin.com/in/ollehallin
>>
>>
>>
>> 2010/1/21 Andy Clement <andrew.clement@xxxxxxxxx>
>>>
>>> Hi Olle,
>>>
>>> yes, that is the main option I am considering (as it is minimal effort
>>> on my part) but I mainly posted to know how much pain a change like
>>> this would cause as this is something that always 'just works' with
>>> the existing strategy.  If enough users complained that it would
>>> affect them, I would try come up with a more sophisticated solution,
>>> but so far no-one seems to mind.  So far I've only ever seen this come
>>> up with AspectJ test programs that are deliberately trying to do it, I
>>> don't have a real world scenario that demonstrates the need for it.
>>>
>>> cheers,
>>> Andy
>>>
>>> 2010/1/21 Olle Hallin <olle.hallin@xxxxxx>:
>>> > Why not let transparent weaving be default, with compile error for name
>>> > clashes?
>>> > If someone (perhaps much later) writes a second ITD (or uses a
>>> > third-party
>>> > aspect) that causes a name clash, only then the transparent weaving
>>> > must be
>>> > disabled.
>>> > Olle Hallin
>>> > Senior Java Developer and Architect
>>> > olle.hallin@xxxxxxxx
>>> > www.crisp.se
>>> > http://www.linkedin.com/in/ollehallin
>>> >
>>> >
>>> > 2010/1/20 Andy Clement <andrew.clement@xxxxxxxxx>
>>> >>
>>> >> I'm currently looking at transparent weaving, this is where the
>>> >> resultant bytecode looks more like the user might guess it would based
>>> >> on their declarations.  Consider:
>>> >>
>>> >> class Foo {
>>> >> }
>>> >>
>>> >> aspect Bar {
>>> >>  private int Foo.i
>>> >> }
>>> >>
>>> >> Compiling that will not give field 'i' on Foo *if* you look at
>>> >> Foo.class through javap.  Instead it will be a mangled name.  I would
>>> >> like to preserve the name but it leaves me with this problem:
>>> >>
>>> >> class Foo { }
>>> >>
>>> >> aspect BarOne {
>>> >>  private int Foo.i
>>> >> }
>>> >>
>>> >> aspect BarTwo {
>>> >>  private int Foo.i
>>> >> }
>>> >>
>>> >> which, with the 'old style' of ITDs will work fine as the mangled
>>> >> names won't clash.  In a transparent weaving world I'm trying to
>>> >> decide the best way to handle it, so I thought I'd ask here if anyone
>>> >> is actually doing it?
>>> >> The options would seem to be:
>>> >> - make it a compile error to do it (seems a shame when it could be
>>> >> done
>>> >> before)
>>> >> - one of them gets the name 'i' and the other gets a mangled name.
>>> >> Possible but a lot of implementation work.
>>> >> - make transparent weaving an option and not the default mode, so a
>>> >> user has to request it at compile time. (I'd rather avoid this if I
>>> >> can and have transparent be the default)
>>> >>
>>> >> Remember, there is no change here to ITD semantics, purely in how they
>>> >> are represented in the resultant bytecode.  So - do you ever ITD the
>>> >> same named field onto a type from two different aspects?
>>> >>
>>> >> thanks,
>>> >> Andy
>>> >> _______________________________________________
>>> >> aspectj-users mailing list
>>> >> aspectj-users@xxxxxxxxxxx
>>> >> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>>> >
>>> >
>>> > _______________________________________________
>>> > aspectj-users mailing list
>>> > aspectj-users@xxxxxxxxxxx
>>> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
>>> >
>>> >
>>> _______________________________________________
>>> aspectj-users mailing list
>>> aspectj-users@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>>
>>
>> _______________________________________________
>> aspectj-users mailing list
>> aspectj-users@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>>
>
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>