Re: [aspectj-dev] AspectJ Custom Attributes

["Wes Isberg" <wes@xxxxxxxxxxxxxx>]

> I am afraid that none of them would allow to use code weaved by 
> AspectJ.

As I understand it, this issue only affects people doing load-time
weaving where the AspectJ weaver is in a chain with ASM, because ASM 
is stripping the crosscutting information from the .class file so the
weaver can't use it (the weaver doesn't make a copy).  I take it
Hibernate is one of them.  That's confirmed, right?  Hibernate's
popularity does drive this, but build-time weaving could be an 
ok workaround for 1.5.0.  People can upgrade to 1.5.1 when 
working with older ASM versions.

Perhaps the first step is some design specifying issues/
requirements and propose implementations.  e.g.,

- run under java 1.1 and do LTW under 1.3-1.5 [CLASS]
- mechanism for reading binary aspects built since 1.2.1
  - version prefix - local, runtime, or compiler?
- reduce class sizes
- ...

A motivation section would help:
- collision with ASM
  - collision with hibernate
    - build-time weaving insufficient b/c ...
  - WebLogic 9 diagnostic layer
    - build-time weaving insufficient b/c ...

(Andy's not signed up for that, Adrian's unavailable,
and Alex is the main expert on point...)  

wrt implementation, a big/forgotten work item might 
be to write some tests.

Wes

> ------------Original Message------------
> From: Eugene Kuleshov <eu@xxxxxxxx>
> To: "AspectJ developer discussions" <aspectj-dev@xxxxxxxxxxx>
> Date: Fri, Oct-21-2005 1:38 PM
> Subject: Re: [aspectj-dev] AspectJ Custom Attributes
>
> 
>    It is sad, but I think Alex have point here even it is ASM's 
> "fault" at some extent.
> 
>    The worst case is Hibernate. There are lot of apps using Hibernate, 
> which is using CGLIB, which is using ASM. As you may guess that chain 
> may bring up lot of ancient versions of Hibernate, CGLIB nad ASM tools 
> and I am afraid that none of them would allow to use code weaved by 
> AspectJ. Though more recent versions that support annotation 
> attributes will work (especially if users are moved to 
> annotation-enabled hibernate).
> 
>    regards,
>    Eugene
> 
> 
> Alexandre Vasseur wrote:
> > I still argue we should do it in the 1.5.0 timeframe.
> > ASM as it is is already widespread, so don't expect a fixed version
> > that will pass the custom attributes through to be packaged in
> > products soon.
> > 
> > Does someone have a fix date requirement for 1.5.0 final or? I 
> already
> > feel that we all spend more time debating than doing it...
> > There are several way more important changes than some internals like
> > this one (new style, generics, all java5 stuff is way more than just
> > that) and adding this change to the 1.5.0 final makes total sense.
> > As I said moving to more complex annotation is not a big deal as it 
> is
> > not possible for most of them (I can look more and write down the
> > list) and as I said it does not make that much sense for runtime
> > invisible annotations. Hence the design is pretty much easy to agree
> > on. I would argue to have one annotation for each AJ attribute, as
> > there cannot be the same attribute twice but there can be several
> > different attributes on the same target member. This also opens for
> > versionning as Eugene introduced but as this is already in
> > WeaverVersionInfo I don't see the need for versionning at that finer
> > level - unless someone see a use case.
> > 
> > To add to the mix I just checked and WebLogic 9 ships ASM as part of
> > its own core diagnostic layer, and obviously will discard all those
> > attributes when the layer will be turned on.
> > So this is just beeing even more pragmatic.
> > 
> > Alex
> > 
> > 
> > 
> > On 10/21/05, Ron Bodkin <rbodkin@xxxxxxxxxxxxxx> wrote:
> > 
> >>It seems to me that if AspectJ moves to annotations instead of custom
> >>attributes, it would be reasonable to do it in a dot release (5.0.2?) 
> after
> >>a careful design.  Hopefully ASM will include support for AspectJ 5
> >>attributes given that they are not using the constant pool, hence 
> should
> >>work properly given your proposal Eugene.
> >>
> >>For users who want easy support in (other) tools like ASM, they could
> >>recompile their code with the new release to interoperate better. If 
> they
> >>have a binary jar they can just reweave it ;-) So forward migration 
> wouldn't
> >>be too bad.
> >>
> >>None of this would obviate the need for backward compatibility: 
> AspectJ
> >>already has to support aspects in 1.1.x and 1.2.x bytecode format 
> with
> >>custom attributes. Adding 1.5.0 into the mix doesn't seem to me to 
> make
> >>matters that much.
> >>
> >>Moreover, I think Andy's right to want to defer this until after 5.0, 
> and if
> >>a new format is decided on, it's worth taking some time to make it 
> optimal.
> >>On the other hand, if ASM supports AspectJ attributes, it's also 
> worth
> >>looking to see what other bytecode modification tools are important 
> enough
> >>to justify the effort, possible instability, and code bloat of 
> supporting
> >>yet another format going forward.
> >>
> >>-----Original Message-----
> >>From: aspectj-dev-bounces@xxxxxxxxxxx
> >>[mailto:aspectj-dev-bounces@xxxxxxxxxxx] On Behalf Of Eugene Kuleshov
> >>Sent: Friday, October 21, 2005 8:26 AM
> >>To: AspectJ developer discussions
> >>Subject: Re: [aspectj-dev] AspectJ Custom Attributes
> >>
> >>Andy Clement wrote:
> >>
> >>
> >>>This point you made is very interesting and hadn't crossed my mind 
> before:
> >>>
> >>>
> >>>>  Another huge reason is that annotation attributes allow to reuse
> >>>>and benefit from the class constant pool. So, you can share the 
> same
> >>>>string, class and other literals and constants with the rest of the
> >>>>class bytecode. That not only decreases the bytecode size, but also
> >>>>give additional simplicity for static bytecode analysers (including
> >>>>tools like jarjar).
> >>>
> >>>We made the AspectJ 'reweavable' option the default recently which 
> has
> >>>increased the size of class files we create - this would be a way to
> >>>recover some of that space... however, if we just took what we store
> >>>in attributes at the moment and stuffed it into annotation with a
> >>>'byte[] value' in it, we wouldn't get this benefit... so clearly 
> some
> >>>detailed thought needs to go into any potential switchover to
> >>>annotations.
> >>
> >>  That is absolutely right. There would be no real size and
> >>structural advantages in just using some annotation with byte[] or
> >>String property, though it still would be more transparent to the 3rd
> >>paty tools.
> >>
> >>
> >>>And that is really my concern over doing it - the required 
> engineering
> >>>effort given that 1.5 has been under development for what feels like
> >>>forever and we just want to ship the darn thing.  At some point we
> >>>have to draw a line and say *thats it, no more goodies in this
> >>>release*.
> >>
> >>  That is fair. I absolutely agree that it is very important to
> >>release this version.
> >>  However it would make sense to think about some migration strategy
> >>if AspectJ will decide to switch away from the custom attrs (which
> >>look very unlikely).
> >>
> >>
> >>>To move to annotations properly we need to ensure we
> >>>continue to support reading in old format .class files and we need 
> to
> >>>make sure we can manipulate the annotations correctly without the
> >>>compiler getting a 1.5 dependency (I know this can be done, I just
> >>>think it needs some thought rather than being hacked in) - i think
> >>>those kind of changes would cause us to ship a  Milestone5 build 
> next
> >>>rather than ReleaseCandidate1.  It would be a shame to rush an
> >>>implementation into 1.5.0 and be stuck with it after that ...
> >>
> >>  Anyway, I do agree that it will require some time to came with good
> >>attribute-based implementation. That is why I am being pushy in this
> >>topic. :-)
> >>
> >>  By the way, using annotation attributes does _not_ enforce you to
> >>have 1.5 dependency in the compiler neither have Annotation classes
> >>around to read the content of these attributes when working with
> >>bytecode directly. Especially if you would use CLASS they all going 
> to
> >>be ignored by VM.
> >>  More over, if you can make an assumption that content of these
> >>annotations is valid (that is very reasonable for AJ own
> >>annotations/custom attributes) you can actually generate these
> >>Annotation classes on the fly from the content of the attributes
> >>(except maybe that you won't see unused optional properties), e.g. to
> >>be used with reflective calls to Java5 introspection API... or use
> >>some custom accessors like I've illustrated in one of my ASM articles
> >> or the one Alex and Jonas implemented in backport175.
> >>
> >>  regards,
> >>  Eugene
> 
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>