Re: [aspectj-dev] AspectJ Custom Attributes

[Alexandre Vasseur <avasseur@xxxxxxxxx>]

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
>
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>