| Status and future plans for AspectJ/AJDT? (mustang support in particular) [message #63421] |
Sun, 02 April 2006 11:57  |
Eclipse User |
|
|
|
Originally posted by: nospam.nospam.no
With AspectJ/AJDT since December offering full support for JDK1.5 and
runtime weaving and lots of other great new stuff, what are the current and
future plans for AspectJ/AJDT ? In particular what will happen with
AspectJ/AJDT in order to be compatible with Mustang and Eclipse 3.2 as they
are released later this year ?
Will AspectJ play nice with the changes to the class format in mustang and
with the integrated JSR 269 annotation processor in the javac 1.6 compiler
(among other issues, if ajc is continue to be a viable replacement for javac
surely it must also support the internal annotation processor).
The reason I ask it that I would like to be able to use JDK1.6 with it's new
JSR 269 annotation processing + eclipse 3.2 + AspectJ/AJDT (and maybe Spring
but that is another issue). Will that be possible? If yes, when ?
Thanks,
Morten
|
|
|
|
|
|
|
|
| Re: Status and future plans for AspectJ/AJDT? (mustang support in particular) [message #63693 is a reply to message #63513] |
Mon, 03 April 2006 22:35  |
| Eclipse User |
|
|
|
Andy,
I'd be interested to know about your findings about Java6 class file
format changes. More specifically how are you going to calculate or
update ClassMapTable data structures that are added for bytecode version
50. Basic idea is that for each conditional branch you have to provide
state information for local variables as well as stack state. There is
some optimization can be used to compress such info (e.g. use delta from
previous stack frame).
So, when method bytecode is changed by AJ weaver, and when bytecode
version is 50+, stack map frames has to be recalculated if woven code
changed or added new variables or stack frames or introduced new
conditional branches or try catch blocks. You can, of course downgrade
bytecode version to 49 (Java 5 level) to fall back to old verifier and
this would not make much of the difference (unless someone will use
undocumented jvm options to force use of new verifier) since there are
no new features introduced in Java 6.
By the way, if there are plans to migrate AJ code to use ASM for
bytecode manipulation? It has been suggested some time ago and decision
been postponed till AJ 5 release.
regards,
Eugene
PS: While working on Java 6 support in ASM framework we did some
research around partial stack map updates and implemented incremental
transformer for LocalVariableSorter adapter (which allows to introduce
new variables and renumber existing vars). We also have option to
recalculate stack map info from scratch and to expand packed frames.
Andy Clement wrote:
....
> And i'll take the AspectJ question. When Eclipse 3.2 is 'complete' we
> will upgrade AspectJ to be based on that level of the compiler. At that
> point we will pick up their support for jsr202 (class file format
> changes) and jsr269 (annotation processing spec). I know support for the
> former is already in the 3.2 milestones, but I don't think full support
> for jsr269 is (feel free to correct me if I'm wrong??). There will be
> an outstanding question about the class file format changes and our
> weaver which I've not tackled yet.
>
> Aim for the next few days is AspectJ1.5.1 - I have one more incremental
> compilation bug to fix before it ships. As Matt says, the main focus
> right now is that we want to scale up and build larger projects, in
> shorter time and using less memory - and 1.5.1 (and accompanying AJDT)
> is a first step towards that, requiring half the memory that 1.5.0 did
> under Eclipse.
>
> Andy.
|
|
|
|
|
|
|
|
|
| Re: Status and future plans for AspectJ/AJDT? (mustang support in particular) [message #593003 is a reply to message #63513] |
Mon, 03 April 2006 22:35 |
| Eclipse User |
|
|
|
Andy,
I'd be interested to know about your findings about Java6 class file
format changes. More specifically how are you going to calculate or
update ClassMapTable data structures that are added for bytecode version
50. Basic idea is that for each conditional branch you have to provide
state information for local variables as well as stack state. There is
some optimization can be used to compress such info (e.g. use delta from
previous stack frame).
So, when method bytecode is changed by AJ weaver, and when bytecode
version is 50+, stack map frames has to be recalculated if woven code
changed or added new variables or stack frames or introduced new
conditional branches or try catch blocks. You can, of course downgrade
bytecode version to 49 (Java 5 level) to fall back to old verifier and
this would not make much of the difference (unless someone will use
undocumented jvm options to force use of new verifier) since there are
no new features introduced in Java 6.
By the way, if there are plans to migrate AJ code to use ASM for
bytecode manipulation? It has been suggested some time ago and decision
been postponed till AJ 5 release.
regards,
Eugene
PS: While working on Java 6 support in ASM framework we did some
research around partial stack map updates and implemented incremental
transformer for LocalVariableSorter adapter (which allows to introduce
new variables and renumber existing vars). We also have option to
recalculate stack map info from scratch and to expand packed frames.
Andy Clement wrote:
....
> And i'll take the AspectJ question. When Eclipse 3.2 is 'complete' we
> will upgrade AspectJ to be based on that level of the compiler. At that
> point we will pick up their support for jsr202 (class file format
> changes) and jsr269 (annotation processing spec). I know support for the
> former is already in the 3.2 milestones, but I don't think full support
> for jsr269 is (feel free to correct me if I'm wrong??). There will be
> an outstanding question about the class file format changes and our
> weaver which I've not tackled yet.
>
> Aim for the next few days is AspectJ1.5.1 - I have one more incremental
> compilation bug to fix before it ships. As Matt says, the main focus
> right now is that we want to scale up and build larger projects, in
> shorter time and using less memory - and 1.5.1 (and accompanying AJDT)
> is a first step towards that, requiring half the memory that 1.5.0 did
> under Eclipse.
>
> Andy.
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04752 seconds
Home