[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
