Actually we are wrighting our own weaver, not compiler. And we've made our
make aspect-aware too, so that only necesary files are
woven/rewoven. What does weaver mean? Is it post compile or pre-compile (working on src
or on class file). Is it the technology you use to add the ctor to form classes in the GUI build/fw. Will the ant task benefit from the weaving optimization too? Will aspects compile in IDE would not be recompiled outside through ant?
Using AOP terminology, the weaver is the post-processor that inserts the advice code at the join points, identified by pointcuts.
Is it post compile or pre-compile (working on src or on class file).
Both. Some AspectJ features, such as introduction, will require modifications at the source code level: in this case we'll create a temporary java file and will use it instead of original one in the compilation. Advice code insertion will be handled by the byte-code weaver.
>Is it the technology you use to add the ctor to form
classes in the GUI build/fw.
No, but similar. The nessesary bytecode is "injected" by the so called FormCompiler. (it is actually a post-processor too)
Will the ant task benefit from the weaving optimization too?
What do you mean?
Will aspects compile in IDE would not be recompiled outside through ant?
If the question is whether we are planning to provide a way to compile aspects outside IDEA, then yes, just like with UI Designer, we are going to provide an Ant task.
--
Best regards, Eugene Zhuravlev JetBrains, Inc, http://www.intellij.com "Develop with pleasure!"
>>Is it post compile or pre-compile (working on src >>or on class file).
Both. Some AspectJ features, such as introduction, will require modifications at the source code level: in this case we'll create a temporary java file and will use it instead of original one in the compilation. Advice code insertion will be handled by the byte-code weaver.
What about debug line numbers? If you modify temporary source and then compile won't the debug lines be off?
Also, other AOP systems perform introductions using byte-code modifications. Was there a specific reason not to take that approach?
Will the ant task benefit from the weaving optimization too?
>
What do you mean?
> How do know which classes in the system needs to be advised w/o analysis of every class? I suppose you keep a database of the weaving info that you keep up-to-date at each compile. That way you can quickly determine the files that has changed and needs to be re-analysed and the ones that didn't changed but need to be re-advised. If this is the case, will the ant task use such an approach and will it be possible to share the db between IDEA and ant.
I suppose you keep a database of the weaving info that you keep up-to-date at each compile. That way you can quickly determine the files that has
Yes, and we also rely on dependency information that our "make" builds as well as PSI. The plans are to provide an "offline make" ant task, which will also be capable of compiling java classes incrementally as a side effect. The core of the task will be actually IDEA's "make" and of course, the dependency data, that it will generate could be used by IDEA's integrated make. Since the make is aspect-aware, all weaving optimizations will be present.
--
Best regards, Eugene Zhuravlev JetBrains, Inc, http://www.intellij.com "Develop with pleasure!"
What about debug line numbers? If you modify temporary source and then compile won't the debug lines be off?
>
Well, we can always keep instrumented source and display it in debugger instead of original one.
Also, other AOP systems perform introductions using byte-code modifications. Was there a specific reason not to take that approach?
If the introduced members are used only by aspects, it is possible to introduce them at byte-code level, but in general Mike is right - we have to do source instrumentations because some classes may use members, introduced by aspects - this is allowed by AspectJ.
--
Best regards, Eugene Zhuravlev JetBrains, Inc, http://www.intellij.com "Develop with pleasure!"
Well, we can always keep instrumented source and display it in debugger instead of original one.
If anyone here is old enough to remember the days of C++ where C++ was converted into C, and compiled with C Compilers. Early versions of the debuggers would display the modified source code, not the real code.
It really sucked.
As a temporary solution to get the features out, that is fine. But a more permement solution would need to be found for it to be widely adopted.
I suppose you keep a database of the weaving info that you keep
up-to-date
at each compile. That way you can quickly determine the files that has
>
Yes, and we also rely on dependency information that our "make" builds as
well as PSI.
The plans are to provide an "offline make" ant task, which will also be
capable of compiling java classes incrementally as a side
effect. The core of the task will be actually IDEA's "make" and of course,
the dependency data, that it will generate could be used
by IDEA's integrated make. Since the make is aspect-aware, all weaving
optimizations will be present. Does "Could" mean "in theory" and you might not have this initialy? Should I file a request to make sure it gets in? On our big projects (>5K classes) this would be extremely important. Right now sometimes IDEA make or the ant javac recompiles things that it should not. I've never been able to pinpoint the problem however. So using the same compiler would solve this problem. Is it more complex than extracting the compiler and be able to configure ant task and/or IDEA compiler to point to the same system dir?
Jacques
--
>
Best regards, Eugene Zhuravlev JetBrains, Inc, http://www.intellij.com "Develop with pleasure!"
Does "Could" mean "in theory" and you might not have this initialy?
Since the code inside IDEA and in the task will be the same, there will be full compatibility :)
>Should I
file a request to make sure it gets in?
Sure :)
Is it more complex than extracting the compiler and be able to configure ant task and/or IDEA compiler to point to the same system dir?
Currently dependency information is stored in the output directory under the .dependency-info directory, so it will be found automatically. The job will mainly consist in extracting the compiler code.
--
Best regards, Eugene Zhuravlev JetBrains, Inc, http://www.intellij.com "Develop with pleasure!"
Mike Aizatsky wrote: >>Also, other AOP systems perform introductions using byte-code >>modifications. Was there a specific reason not to take that approach?
I think it's impossible to compile a file, which references the introduced field, without having the instrumented source.
Yes, I was not refering to the using code but the introduced code itself.
I suspect that would be the solution. This is implemented in the jvm already, isn't it. I remember seeing that jbiulder8 support jsr45.
Yep, there's the API added in jdk 1.4 that allows to obtain extended debug info. Unfortunately, there are no servers (I know about Tomcat 5 alpha only) yet that generate this info.
--
Best regards, Eugene Zhuravlev JetBrains, Inc, http://www.intellij.com "Develop with pleasure!"
Actually we are wrighting our own weaver, not compiler. And we've made our make aspect-aware too, so that only necesary files are
woven/rewoven.
--
Best regards,
Eugene Zhuravlev
JetBrains, Inc, http://www.intellij.com
"Develop with pleasure!"
"Jacques Morel" <jacmorel@yahoo.com> wrote in message news:bch307$2d4$1@is.intellij.net...
>
>
>
"Eugene Zhuravlev" <jeka@intellij.com> wrote in message
news:bcjm72$p4i$1@is.intellij.net...
make aspect-aware too, so that only necesary files are
or on class file). Is it the technology you use to add the ctor to form
classes in the GUI build/fw.
Will the ant task benefit from the weaving optimization too? Will aspects
compile in IDE would not be recompiled outside through ant?
Jacques
Using AOP terminology, the weaver is the post-processor that inserts the advice code at the join points, identified by pointcuts.
Both. Some AspectJ features, such as introduction, will require modifications at the source code level: in this case we'll create a
temporary java file and will use it instead of original one in the compilation. Advice code insertion will be handled by the
byte-code weaver.
>Is it the technology you use to add the ctor to form
No, but similar. The nessesary bytecode is "injected" by the so called FormCompiler. (it is actually a post-processor too)
What do you mean?
If the question is whether we are planning to provide a way to compile aspects outside IDEA, then yes, just like with UI Designer,
we are going to provide an Ant task.
--
Best regards,
Eugene Zhuravlev
JetBrains, Inc, http://www.intellij.com
"Develop with pleasure!"
Eugene Zhuravlev wrote:
>>Is it post compile or pre-compile (working on src
>>or on class file).
What about debug line numbers? If you modify temporary source and then
compile won't the debug lines be off?
Also, other AOP systems perform introductions using byte-code
modifications. Was there a specific reason not to take that approach?
>
>
How do know which classes in the system needs to be advised w/o analysis of
every class?
I suppose you keep a database of the weaving info that you keep up-to-date
at each compile. That way you can quickly determine the files that has
changed and needs to be re-analysed and the ones that didn't changed but
need to be re-advised.
If this is the case, will the ant task use such an approach and will it be
possible to share the db between IDEA and ant.
Jacques
I think it's impossible to compile a file, which references the introduced
field, without having the instrumented source.
--
Best regards,
Mike Aizatsky.
-
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"
Yes, and we also rely on dependency information that our "make" builds as well as PSI.
The plans are to provide an "offline make" ant task, which will also be capable of compiling java classes incrementally as a side
effect. The core of the task will be actually IDEA's "make" and of course, the dependency data, that it will generate could be used
by IDEA's integrated make. Since the make is aspect-aware, all weaving optimizations will be present.
--
Best regards,
Eugene Zhuravlev
JetBrains, Inc, http://www.intellij.com
"Develop with pleasure!"
>
Well, we can always keep instrumented source and display it in debugger instead of original one.
If the introduced members are used only by aspects, it is possible to introduce them at byte-code level, but in general Mike is
right - we have to do source instrumentations because some classes may use members, introduced by aspects - this is allowed by
AspectJ.
--
Best regards,
Eugene Zhuravlev
JetBrains, Inc, http://www.intellij.com
"Develop with pleasure!"
If anyone here is old enough to remember the days of C++ where C++ was converted into C, and compiled with C Compilers. Early versions of the debuggers would display the modified source code, not the real code.
It really sucked.
As a temporary solution to get the features out, that is fine. But a more permement solution would need to be found for it to be widely adopted.
Mike
adopted.
JSR 45?
--
Best regards,
Mike Aizatsky.
-
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"
Awesome! Just what I was looking for to put my Eclipse guys back in their
goal ;)
I suppose this will be available as part of the compiler task?
"Eugene Zhuravlev" <jeka@intellij.com> wrote in message
news:bcpv0j$mrh$1@is.intellij.net...
up-to-date
>
well as PSI.
capable of compiling java classes incrementally as a side
the dependency data, that it will generate could be used
optimizations will be present.
Does "Could" mean "in theory" and you might not have this initialy? Should I
file a request to make sure it gets in?
On our big projects (>5K classes) this would be extremely important. Right
now sometimes IDEA make or the ant javac recompiles things that it should
not. I've never been able to pinpoint the problem however. So using the same
compiler would solve this problem.
Is it more complex than extracting the compiler and be able to configure ant
task and/or IDEA compiler to point to the same system dir?
Jacques
>
>
>
Since the code inside IDEA and in the task will be the same, there will be full compatibility :)
>Should I
Sure :)
Currently dependency information is stored in the output directory under the .dependency-info directory, so it will be found
automatically. The job will mainly consist in extracting the compiler code.
--
Best regards,
Eugene Zhuravlev
JetBrains, Inc, http://www.intellij.com
"Develop with pleasure!"
Mike Aizatsky wrote:
>>Also, other AOP systems perform introductions using byte-code
>>modifications. Was there a specific reason not to take that approach?
Yes, I was not refering to the using code but the introduced code itself.
Mike Aizatsky wrote:
>>But a more permement solution would need to be found for it to be widely
I suspect that would be the solution. This is implemented in the jvm
already, isn't it. I remember seeing that jbiulder8 support jsr45.
But this is the reason for the source-level instrumentation.
--
Best regards,
Eugene Zhuravlev
JetBrains, Inc, http://www.intellij.com
"Develop with pleasure!"
Yep, there's the API added in jdk 1.4 that allows to obtain extended debug info. Unfortunately, there are no servers (I know about
Tomcat 5 alpha only) yet that generate this info.
--
Best regards,
Eugene Zhuravlev
JetBrains, Inc, http://www.intellij.com
"Develop with pleasure!"
The next version of Orion will too, so any support for this would be wonderful.
When this Orion version is expected to be released?
--
Best regards,
Eugene Zhuravlev
JetBrains, Inc, http://www.intellij.com
"Develop with pleasure!"
"Hani Suleiman" <hani@formicary.net> wrote in message news:9144509.1056043278581.JavaMail.itn@is.intellij.net...