[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-dev] AspectJ Custom Attributes
|
This is a great discussion but I wouldn't consider it for the initial
AspectJ 5 release, not least because Andy said so *smile*. It might
also be good to see the population of conflicts/clients before adopting
an approach. I'm sure ASM won't be the only one.
Wes
> ------------Original Message------------
> From: Eugene Kuleshov <eu@xxxxxxxx>
> To: "AspectJ developer discussions" <aspectj-dev@xxxxxxxxxxx>
> Date: Thu, Oct-20-2005 10:54 AM
> Subject: Re: [aspectj-dev] AspectJ Custom Attributes
>
> Hi folks,
>
> It is good to see such discussion here and I would like to add few
> comments.
>
> I have the same feelings as Alex that AspectJ should use annotation
> attributes instead of inventing the custom attributes for internal
> things.
>
> Answering question Andy Clement asked "Attributes are valid entries
> in the class file, so why would we need to change them into
> annotations?" there are few good reasons.
>
> First of all, as Ron pointed out bytecode is not a closed box.
> There are lot of tools that need to process it and understand the data
> structures that may be affected by such custom processing. This is
> actually very similar to XML - everybody acn read and understand it
> without the code that originally produced it and in many cases even
> without documentation about its structure. For instance tool like
> jarjar can perform string relacement (e.g. regexp based) even if it
> has no clue about meaning of some substring, because user can tweak it
> using additional knowledge about AspectJ.
>
> 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).
>
> With growing popularity of bytecode processing tools (jarjar,
> cobertura, terracota, aspectj, you name it) you can't really count
> that proprietory attributes would survive all the transformations, so
> you have to recover from the case when one of the tools dropped them
> from the bytecode. However that won't be needed if well-known
> annotation atributes are used even for older pre-Java5 bytecode.
> Basically this would make any proprietory aspectj data much more
> transparent to the 3rd party tools.
>
> regards,
> Eugene
>
>
> Ron Bodkin wrote:
> > My statement was true: by default ASM will give errors when
> processing
> > bytecode with custom attributes. I didn't mean to imply that there's
> some
> > fundamental problem (I think that's how you interpreted it). Of
> course ASM
> > can handle them, but until now the default policy has been to not
> accept
> > unknown attributes, and to put the onus on the caller to specifically
> enable
> > them. I previously submitted a patch to jarjar so it can use ASM to
> preserve
> > AspectJ attributes (this is a case where preserving attributes is
> clearly
> > critical).
> >
> > On the good news front, Eugene Kuleshov is proposing a means to
> facilitate
> > using custom attributes and having the AspectJ attributes supported
> by
> > default.
> >
> > When this came up before on the ASM mailing list, one ASM developer
> asked
> > "why aren't you using annotations"? In general, using annotations
> would
> > pick up better tools support. If a change like that were
> contemplated,
> > clearly 5.0 would be the release for it, although I don't think it
> would be
> > worth a delay, an increase in instability, or breaking backward
> > compatibility to achieve.
> >
> > -----Original Message-----
> > From: aspectj-dev-bounces@xxxxxxxxxxx
> > [mailto:aspectj-dev-bounces@xxxxxxxxxxx] On Behalf Of Alexandre
> Vasseur
> > Sent: Thursday, October 20, 2005 7:58 AM
> > To: AspectJ developer discussions
> > Subject: Re: [aspectj-dev] AspectJ Custom Attributes
> >
> > Those are untrue statement about ASM. ASM can handle them. There is
> > just a need of explicit knowledge about those. This is indeed the
> most
> > important limitation in using ASM and AspectJ together.
> >
> > I personally think AspectJ should move to real class level
> annotations
> > instead of custom attributes. There is no need to change a lot of
> > things I think. Some generic class level annotation with a single
> > byte[] attribute is just equivalent to custom attributes - but a bit
> > cleaner and does not requires any special treatment. The deal is
> about
> > handling backward compatibility where needed.
> >
> > Given that ASM is widespread (jarjar, many bytecode based products
> > commercial or not doing performance monitoring or other things etc) I
> > would hope a more pragmatic approach and thinking from all the
> AspectJ
> > dev team about that and ditching the old custom attributes within the
> > 1.5 release time frame. This would solve the issue once and for all
> at
> > the right time.
> > That said I invite ASM folks to give it some more thinking and see if
> > they cannot come up quickly with a defaulted behavior that would keep
> > custom attributes without any special handling. That said AspectJ is
> > at the corner for 1.5 final, while a new version of ASM that would
> > handle this is not (and I remember Eric already told me this was
> > actually not possible given the visitor based design of ASM).
> >
> > Below a code snip to preserve AjAattribute with ASM ( I cross posted
> > on ASM list) for anyone who needs to do that:
> >
> > The AJ attributes are sort of serialized bytes. I think some agnostic
> > wrapper can make the trick for ASM to not lose those and pass them
> > thru as you say.
> >
> > Something like
> > class SerializedAttribute extends asm.Attribute
> > public SerializedAttribute(final String type, final byte[] bytes) {
> > super(type);
> > m_bytes = bytes;
> > }
> > // prepare one prototype for each org.aspectj.weaver.AjAttribute
> inner
> > class:
> > new SerializedAttribute(AjAttribute.Aspect.AttributeName,
> null),
> > new
> SerializedAttribute(AjAttribute.AdviceAttribute.AttributeName,
> > null),
> > //etc.
> >
> > pass an array of prototype when doing the ASM
> ClassReader.accept(...)
> > implement an ASM class adapter with a visitAttribute method
> > This one will gets called for each of the custom AJ attribute
> >>From there you can do like:
> > public void visitAttribute(Attribute attribute) {
> > if
> (attribute.type.startsWith(AjAttribute.AttributePrefix)) {
> > if (attribute instanceof SerializedAttribute) {
> > final byte[] bytes = ((SerializedAttribute)
> > attribute).getBytes();
> > AjAttribute attr = AjAttribute.read(s_version,
> > attribute.type, bytes, null, s_handler);
> >
> > to read the attribute with ASM if you need to.
> >
> > If you don't, just pass it thru (hence don't implement this
> > visitAttribute method if using an adapter etc).
> >
> > Alex
>
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>
