I am working in an ancient java system(the code is really bad, duplications are all over there), but I cannot put the old objects to container(spring). sometimes I want do some tracing, or handling some ugly code like : try {...} catch (Exception e) {return;} the aspectj's static weaving is the best and simplest choice.
Hah! Talk to any AOP expert and they'll gasp in horror at what you're doing. It's the exact wrong use for AOP, you're making bad code so much more unclear and harder to compile for the next poor bastard who has to manage it.
I'm glad you posted though, as surely examples like this show that the aspectJ crowd should be even more ignored than it is currently.
I don't understand why there is so much fear of aspect oriented development. It's just an other tool and has it purposes.
And I would say that using it to instrument legacy code can be quite handy when you do not have the mandate to refactor it but have to work with it. Writing an aspect can also save you time when you have done all you can to find a bug and you are about to start peppering the code with System.out.println(). And not only does it save you time but you won't inadvertantly leave logging statements in the code after.
About debuggers... well you just can't do everything with debugging... ever tried to resolve threading problems with a debugger and have everything work fine when you debug but not when you run the app????!!!
That's only touching the surface of what AOP can do within the development cycle of an app.
I'm not sure there is a fear of it. It is simply regarded by most as a minority feature which should be low on the IDEA priorities list for that reason alone. I've never used it but it seems to me like it could be a good thing, however until it becomes more widely used there seems to be little point investing in it.
Well the comments by are certainly not trying to foster discussion.
> regarded by most as a minority feature which should > be low on the IDEA priorities list for that reason > alone.
What exactly is your evidence that it's a "minority feature"? And even if it is, I think that if software developers only added features when it was obvious that it was needed then very little inovation would come about!
IDEA has always proven that a good interface to existing technologies can make a big difference towards user acceptance. I think the refactoring features demonstrate that very well. Not only were no other IDE's providing this feature 3 years ago when Intellij hit the market, but they have all played catch-up because developers have found that they can no longer live without refactoring tools.
Where refactoring code could take days if not weeks on big projects before... it suddenly became possible to do in hours! And, although that possibility in itself is only an economy of time, it opened up development work to other possibilities.
I think that this is what we, the ones who believe in AOP, feel. That a good editor for aspects will show-off what can be done with it, help ease the learning curve, and open the field to new things.
Actually, refactorings are a terrible analogy. They don't involve a new edito nor do they involve a custom third party product.
I have no objection to some kind of AOP support, but adding support specifically for AspectJ seems...wel...brain damaged, putting it mildly. Of the .05% of java developers who use/care about AOP, I bet that no more than 20% of those use AspectJ. I'd imagine there's a fairly even distribution between Spring, dynaop, aspectwerkz, JBoss AOP, and any other AOP framework which does not mandate its own language.
A better analogy in fact would be 'can we have built in support in IDEA for ATG Dynamo's .jhtml pages'
I'm all for the IDEA guys improving their openAPI enough to allow random users to write plugins for their favourite time wasting 'cool' technology, but having it go into the core and offend everyone who wouldn't possibly care less seems a bit shortsighted, and is a sad indicator that three people yelling loudly enough can indeed determine the direction a product takes.
Well the comments by are certainly not trying to foster discussion.
> regarded by most as a minority feature which should > be low on the IDEA priorities list for that reason > alone.
What exactly is your evidence that it's a "minority feature"? And even if it is, I think that if software developers only added features when it was obvious that it was needed then very little inovation would come about!
IDEA has always proven that a good interface to existing technologies can make a big difference towards user acceptance. I think the refactoring features demonstrate that very well. Not only were no other IDE's providing this feature 3 years ago when Intellij hit the market, but they have all played catch-up because developers have found that they can no longer live without refactoring tools.
Hani's point in this case is that AspectJ is firstly not widely adopted, and for the purposes of what you're trying to do, would have made your code (which was already hard to read because of some lousy engineer) harder to read, and not easier to use.
Second, refactoring enhances code and software, makes (or should) it easier to use, easier to read and understand, and can be carried by anyone using idea, without being bound to it, without introducing new factors in it, and without requiring yet another layer to java to produce what is seemingly good code, when I think if you were using Aspects, it ends up mucking the whole code base with things which require intricate knowledge of what is going on with your pointcuts etc..., and reading the code would be pretty much impossible to do by just anyone who just comes into your project.
I think that this is what we, the ones who believe in AOP, feel. That a good editor for aspects will show-off what can be done with it, help ease the learning curve, and open the field to new things.
And using Aspects without code completion, and using ant to compile it in idea can do the same thing too, without requiring JetBrains to spend brain and people power on things less important. Not having AspectJ integrated doesn't stand in your way, it just makes it less convenient to use, that's all.
> Actually, refactorings are a terrible analogy. They > don't involve a new edito nor do they involve a > custom third party product.
The point was what adding a feature to an IDE can make a difference. When I started using Intellij 1.0 and it ancestor refactoring plugin for JBuilder... people all wondered why I cared about refactoring. Well I think Intellij is part of the reason why refactoring has become such a popular approach in development. Simply because it became efficient with a tool like IntelliJ to do it.
> I have no objection to some kind of AOP support
Well fine, then why not discuss that... maybe there is a better AOP implementation out there... maybe it would be better served by providing an API for it...
> adding support specifically for AspectJ > seems...wel...brain damaged, putting it mildly.
why do you or anyone else need to start calling people names when they disagree with you... forums are for discussion not for bloody fascism
How about all the people who want to discuss AOP post in this thread and the one's who think it's a waste of time don't!
That's pretty simple!!!!
And let JetBrains decide if they care or not. They actually smarter than you think
By posting so many "Why I hate AOP and AspectJ" posts you have more than doubled the number of postings here and made it a hotspot for anyone monitoring this discussion.
Maybe you will even attract AOP supporters who have been sleeping, waiting for the discussion to return! OOOOOH then we will be more then 3... maybe even 5 people. We can surely then dictate to JetBrains to support anything that pleases us!
I tried, but I frankly get annoyed when people start calling others names for expressing their opinions and pretend like they are the only ones who know what's good for IDEA, and for me.
I tried, but I frankly get annoyed when people start calling others names for expressing their opinions and pretend like they are the only ones who know what's good for IDEA, and for me.
To be honest, I think implementing an integration targeting a specific implementation of a technology that isn't widespread is exactly what the OpenAPI and plugins are for. Look at the plugins for JBoss, JIRA, Orion, Maven, etc.
I would love to see some Spring integration in IDEA, but I am not going to push JB to do it. Mostly because there are several products that essentially do the same thing, each has their own following. And bloating the core codebase with that just isn't right.
Personally, I think the time spent (wasted?) on AspectJ integration really hurt IDEA 4.0 when it came to overall features list. By spending all that time on something that didn't get shipped instead of on other features, IDEA 4.0 didn't have near the "Wow" factor that 3.0 did for me. This would have been the chance to really take the lead in J2EE development. It's pretty good as it is, but there are lots of things that could be better.
Hopefully 5.0 will renew the "Wow" for IDEA. It's a great IDE and it's great because they take the everyday things that 99% of all java developers do and make them insanely easy.
I think the calls for AspectJ integration come from a very vocal minority. Why not have IDEA support Struts or WebWork or Spring MVC (which I am fairly certain I could get more responses from on this forum than AspectJ integration)? Because that's the place for plugins.
If AspectJ support is that important to you, get a project together and make a plugin. If the OpenAPI isn't open enough, petition JB to open that up.
ATG DSP rocks. :) JSP 2.0 is still a release or 2 behind. :(
superior marketing > superior engineering
Norris Shelton Sun Certified Java Programmer
Hani Suleiman wrote:
>Actually, refactorings are a terrible analogy. They don't involve a new edito nor do they involve a custom third party product. > >I have no objection to some kind of AOP support, but adding support specifically for AspectJ seems...wel...brain damaged, putting it mildly. Of the .05% of java developers who use/care about AOP, I bet that no more than 20% of those use AspectJ. I'd imagine there's a fairly even distribution between Spring, dynaop, aspectwerkz, JBoss AOP, and any other AOP framework which does not mandate its own language. > >A better analogy in fact would be 'can we have built in support in IDEA for ATG Dynamo's .jhtml pages' > >I'm all for the IDEA guys improving their openAPI enough to allow random users to write plugins for their favourite time wasting 'cool' technology, but having it go into the core and offend everyone who wouldn't possibly care less seems a bit shortsighted, and is a sad indicator that three people yelling loudly enough can indeed determine the direction a product takes.
To be honest, I think implementing an integration targeting a specific implementation of a technology that isn't widespread is exactly what the OpenAPI and plugins are for. Look at the plugins for JBoss, JIRA, Orion, Maven, etc.
To say that it can be a plug-in is fine although not much of an argument in my opinion.
Personally, I think the time spent (wasted?) on AspectJ integration really hurt IDEA 4.0 when it came to overall features list. By spending all that time on something that didn't get shipped instead of on other features, IDEA 4.0 didn't have near the "Wow" factor that 3.0 did for me.
Sure I can agree with that... but that's just how things go with software development. What happened with AspectJ could have happened with many other things.
If you or anyone has good idea on what Intellij should spend their time on then by all means post it. I think that would be more constructive than repeating over and over that any form of AOP intetegration is not worth it.
If AspectJ support is that important to you, get a project together and make a plugin. If the OpenAPI isn't open enough, petition JB to open that up.
But then that can be said about anything. It can be said about any vendor specific integration that anyone will talk about.
And discussing the subject could lead to creating a plugin... could lead to a different approach... or maybe to finding what OpenAPI channels are needed. Maybe there are enough similar AOP api's out there that a common AOP api is possible. I don't know...
I conceed AspectJ is not neccessarily the best API out ther for AOP. And as I have learned, through this forum, I have looked up other APIs that are out there.
I still maintain that AOP(not AspectJ specifically) is an interesting idea for integration into IDEA... plugin or core feature or something else.
And that's really what I would like to discuss. Could all the folks who have negative opinions about AspectJ say if it's only AspectJ they are against, or any AOP being a core feature of IDEA. What are the other APIs out there worth lookin at... I took a breif look at AspectWerkz and that looks like it has potential... and maybe it could be supported by a plug-in rather than full integration...
And that's really what I would like to discuss. Could all the folks who have negative opinions about AspectJ say if it's only AspectJ they are against, or any AOP being a core feature of IDEA. What are the other APIs out there worth lookin at... I took a breif look at AspectWerkz and that looks like it has potential... and maybe it could be supported by a plug-in rather than full integration...
I think the problem at this point is there is no "standard" AOP API the could be used generically in an IDE. At some point, sepecific implementations would need to be written.
I'm not against AOP, in fact, I use it daily, just not at the AspectJ level of needing another compiler. But the types of AOP I use don't require the IDE to show many anything or do anything for me, even for debugging.
And as for your other points, that's all true. Sure, they could have not done a Weblogic integration, but that is a fairly large market and was their choice and I guess people are using it.
Even in 5.0, I know I'm happy they are doing both Subversion and Perforce since I happen to use them both. But again, these are larger markets ( in the Subversion area, that's possibly debatable ) than I think for a AOP solution since almost every developer has to deal with some sort of VCS.
Like Patrick mentions, if I were to use AOP, I'd use the implementation in Spring. I don't need extra compiler, I don't need my IDE to do anything special, I just use it.
So I want to flip the question around, why don't you find an AOP impl which does not require IDE specific integration and just use that? Why is it that JetBrains needs to write SOME KIND of AOP impl to satisfy the few, when the need of the many can be served already?
So I want to flip the question around, why don't you find an AOP impl which does not require IDE specific integration and just use that? Why is it that JetBrains needs to write SOME KIND of AOP impl to satisfy the few, when the need of the many can be served already?
I don't absolutely want IntelliJ to do this for me. Just like anyone else, I am looking for making work-flow integration optimal.
I also want to debate it and here about others experience. And as of the last posts I am getting that.
Orthogonality is a big issue for me. And that's one thing AspectJ provides. And looking at other AOP frameworks I would want to have that. I am not sure I will get that with Spring framework... maybe with aspectWerks.
I don't understand why there is so much fear of aspect oriented development. It's just an other tool and has it purposes.
There is no fear of AOP; that's just something that its supporters say when they can't come up with good examples of its use.
And I would say that using it to instrument legacy code can be quite handy when you do not have the mandate to refactor it but have to work with it. Writing an aspect can also save you time when you have done all you can to find a bug and you are about to start peppering the code with System.out.println(). And not only does it save you time but you won't inadvertantly leave logging statements in the code after.
That's when I tend to use a debugger.
About debuggers... well you just can't do everything with debugging... ever tried to resolve threading problems with a debugger and have everything work fine when you debug but not when you run the app????!!!
Nope. But there are loads of GUI tools that let you watch object allocation and threads, without having to build aspects into your code (which can have exactly the same effect).
Well the comments by are certainly not trying to foster discussion.
I think the comments here are aimed at keeping JetBrains focussed on core stuff that IDEA needs. I would say the same thing if someone suggested adding ColdFusion support to IDEA, even though I am also a big fan of ColdFusion.
IDEA has always proven that a good interface to existing technologies can make a big difference towards user acceptance. I think the refactoring features demonstrate that very well.
Refactoring didn't need 'user acceptance'. Folk have been maintaining code since day one.
I think that this is what we, the ones who believe in AOP, feel. That a good editor for aspects will show-off what can be done with it, help ease the learning curve, and open the field to new things.
You don't even have any sort of standard way of doing this yet ... which particular implementation of Aspects should they support.
why do you or anyone else need to start calling people names when they disagree with you... forums are for discussion not for bloody fascism
The BileMan has a point though (not the brain-damage part obviously); aside from being of interest to only a minute fraction of the Java community, which implementation will they support?
The BileMan has a point though (not the brain-damage part obviously); aside from being of interest to only a minute fraction of the Java community, which implementation will they support?
Well... actually I have been researching this since everyone is so convinced that no one out there is supporting AOP! I have just discovered http://aopalliance.sourceforge.net . It's an API for standardisiing AOP support.
such products as Spring, AspectWerkz, Resin, Nanning and others seem to be basing their AOP efforts on this API.
Anybody know anything about it? Maybe this is what IDEA could provide support for?
Well... actually I have been researching this since everyone is so convinced that no one out there is supporting AOP! I have just discovered http://aopalliance.sourceforge.net . It's an API for standardisiing AOP support.
Well, a handful of web pages, does not an alliance make ... :)
And who said no-one was supporting AOP? What we said was that the proportion of the Java Community that uses it, is a very tiny (if vocal) percentage.
AOP Alliance is pretty much a failure. Many of the frameworks support it, but it's pretty stagnant and the API doesn't seem to be moving forward very much.
Having said that, it's also a pure java API, so there's no integration to IDEA needed before you can start writing your aspects. Kinda worrying that the knee jerk reaction is to want it integrated to IDEA before even knowing what it is and how it works.
You're right in that this debate has proven useful, in that the non-AspectJers didn't do what we did last time and mostly stayed quiet (as you suggested, because they just didn't care about it, so they didn't feel they had anything to contribute to the discussion), with disasterous results. This time we're fighting fire with fire!
Note also that I said AspectJ, not AOP. I have no issue with a bunch of you clever AOP people getting together and wasting your own time writing a plugin, and then complaining to the IDEA people about holes in the openAPI that are making your job difficult. I just don't want to ever see aspectJ or AOP as part of the core product.
I don't know how good this is, but I once thought about Code coverage tool with the help as AspectJ.
We insert Logging like statements in some predefined format, which gets saved into a global file (or data structure) and then there will be a tool to process it and tell about the statistics :)
Or you could simply choose not to use AspectJ... ;)
Hi Aeros, for what purpose you need AspectJ?
Tom
I am working in an ancient java system(the code is really bad, duplications are all over there), but I cannot put the old objects to container(spring). sometimes I want do some tracing, or handling some ugly code like :
try {...} catch (Exception e) {return;}
the aspectj's static weaving is the best and simplest choice.
Hah! Talk to any AOP expert and they'll gasp in horror at what you're doing. It's the exact wrong use for AOP, you're making bad code so much more unclear and harder to compile for the next poor bastard who has to manage it.
I'm glad you posted though, as surely examples like this show that the aspectJ crowd should be even more ignored than it is currently.
Actually, I think a good debugger is the best choice .... :-/
I don't understand why there is so much fear of aspect oriented development. It's just an other tool and has it purposes.
And I would say that using it to instrument legacy code can be quite handy when you do not have the mandate to refactor it but have to work with it. Writing an aspect can also save you time when you have done all you can to find a bug and you are about to start peppering the code with System.out.println(). And not only does it save you time but you won't inadvertantly leave logging statements in the code after.
About debuggers... well you just can't do everything with debugging... ever tried to resolve threading problems with a debugger and have everything work fine when you debug but not when you run the app????!!!
That's only touching the surface of what AOP can do within the development cycle of an app.
Florian
I'm not sure there is a fear of it. It is simply regarded by most as a minority feature which should be low on the IDEA priorities list for that reason alone. I've never used it but it seems to me like it could be a good thing, however until it becomes more widely used there seems to be little point investing in it.
> I'm not sure there is a fear of it.
Well the comments by are certainly not trying to foster discussion.
> regarded by most as a minority feature which should
> be low on the IDEA priorities list for that reason
> alone.
What exactly is your evidence that it's a "minority feature"? And even if it is, I think that if software developers only added features when it was obvious that it was needed then very little inovation would come about!
IDEA has always proven that a good interface to existing technologies can make a big difference towards user acceptance. I think the refactoring features demonstrate that very well. Not only were no other IDE's providing this feature 3 years ago when Intellij hit the market, but they have all played catch-up because developers have found that they can no longer live without refactoring tools.
Where refactoring code could take days if not weeks on big projects before... it suddenly became possible to do in hours! And, although that possibility in itself is only an economy of time, it opened up development work to other possibilities.
I think that this is what we, the ones who believe in AOP, feel. That a good editor for aspects will show-off what can be done with it, help ease the learning curve, and open the field to new things.
Florian Hehlen
Actually, refactorings are a terrible analogy. They don't involve a new edito nor do they involve a custom third party product.
I have no objection to some kind of AOP support, but adding support specifically for AspectJ seems...wel...brain damaged, putting it mildly. Of the .05% of java developers who use/care about AOP, I bet that no more than 20% of those use AspectJ. I'd imagine there's a fairly even distribution between Spring, dynaop, aspectwerkz, JBoss AOP, and any other AOP framework which does not mandate its own language.
A better analogy in fact would be 'can we have built in support in IDEA for ATG Dynamo's .jhtml pages'
I'm all for the IDEA guys improving their openAPI enough to allow random users to write plugins for their favourite time wasting 'cool' technology, but having it go into the core and offend everyone who wouldn't possibly care less seems a bit shortsighted, and is a sad indicator that three people yelling loudly enough can indeed determine the direction a product takes.
On 12/7/04 1:47 PM, in article
9829864.1102445223996.JavaMail.itn@is.intellij.net, "Florian Hehlen"
<florian.hehlen@ubsw.com> wrote:
Hani's point in this case is that AspectJ is firstly not widely adopted, and
for the purposes of what you're trying to do, would have made your code
(which was already hard to read because of some lousy engineer) harder to
read, and not easier to use.
Second, refactoring enhances code and software, makes (or should) it easier
to use, easier to read and understand, and can be carried by anyone using
idea, without being bound to it, without introducing new factors in it, and
without requiring yet another layer to java to produce what is seemingly
good code, when I think if you were using Aspects, it ends up mucking the
whole code base with things which require intricate knowledge of what is
going on with your pointcuts etc..., and reading the code would be pretty
much impossible to do by just anyone who just comes into your project.
And using Aspects without code completion, and using ant to compile it in
idea can do the same thing too, without requiring JetBrains to spend brain
and people power on things less important. Not having AspectJ integrated
doesn't stand in your way, it just makes it less convenient to use, that's
all.
R
> Actually, refactorings are a terrible analogy. They
> don't involve a new edito nor do they involve a
> custom third party product.
The point was what adding a feature to an IDE can make a difference. When I started using Intellij 1.0 and it ancestor refactoring plugin for JBuilder... people all wondered why I cared about refactoring. Well I think Intellij is part of the reason why refactoring has become such a popular approach in development. Simply because it became efficient with a tool like IntelliJ to do it.
> I have no objection to some kind of AOP support
Well fine, then why not discuss that... maybe there is a better AOP implementation out there... maybe it would be better served by providing an API for it...
> adding support specifically for AspectJ
> seems...wel...brain damaged, putting it mildly.
why do you or anyone else need to start calling people names when they disagree with you... forums are for discussion not for bloody fascism
Florian
How about all the people who want to discuss AOP post in this thread and the one's who think it's a waste of time don't!
That's pretty simple!!!!
And let JetBrains decide if they care or not. They actually smarter than you think
By posting so many "Why I hate AOP and AspectJ" posts you have more than doubled the number of postings here and made it a hotspot for anyone monitoring this discussion.
Maybe you will even attract AOP supporters who have been sleeping, waiting for the discussion to return! OOOOOH then we will be more then 3... maybe even 5 people. We can surely then dictate to JetBrains to support anything that pleases us!
Get a life!
A very frustrated,
Florian
Sure here you go....
+/- 0 - I might use it for fun if it's there, won't use it on a serious
project, and I won't miss it if it's not.
Is that useful?
Dude, chill.
R
I tried, but I frankly get annoyed when people start calling others names for expressing their opinions and pretend like they are the only ones who know what's good for IDEA, and for me.
Florian
You need a Hani dictionary, that's all :)
R
On 12/7/04 2:37 PM, in article
33333559.1102448274153.JavaMail.itn@is.intellij.net, "Florian Hehlen"
<florian.hehlen@ubsw.com> wrote:
>> Dude, chill.
To be honest, I think implementing an integration targeting a specific implementation of a technology that isn't widespread is exactly what the OpenAPI and plugins are for. Look at the plugins for JBoss, JIRA, Orion, Maven, etc.
I would love to see some Spring integration in IDEA, but I am not going to push JB to do it. Mostly because there are several products that essentially do the same thing, each has their own following. And bloating the core codebase with that just isn't right.
Personally, I think the time spent (wasted?) on AspectJ integration really hurt IDEA 4.0 when it came to overall features list. By spending all that time on something that didn't get shipped instead of on other features, IDEA 4.0 didn't have near the "Wow" factor that 3.0 did for me. This would have been the chance to really take the lead in J2EE development. It's pretty good as it is, but there are lots of things that could be better.
Hopefully 5.0 will renew the "Wow" for IDEA. It's a great IDE and it's great because they take the everyday things that 99% of all java developers do and make them insanely easy.
I think the calls for AspectJ integration come from a very vocal minority. Why not have IDEA support Struts or WebWork or Spring MVC (which I am fairly certain I could get more responses from on this forum than AspectJ integration)? Because that's the place for plugins.
If AspectJ support is that important to you, get a project together and make a plugin. If the OpenAPI isn't open enough, petition JB to open that up.
Patrick
ATG DSP rocks. :) JSP 2.0 is still a release or 2 behind. :(
superior marketing > superior engineering
Norris Shelton
Sun Certified Java Programmer
Hani Suleiman wrote:
>Actually, refactorings are a terrible analogy. They don't involve a new edito nor do they involve a custom third party product.
>
>I have no objection to some kind of AOP support, but adding support specifically for AspectJ seems...wel...brain damaged, putting it mildly. Of the .05% of java developers who use/care about AOP, I bet that no more than 20% of those use AspectJ. I'd imagine there's a fairly even distribution between Spring, dynaop, aspectwerkz, JBoss AOP, and any other AOP framework which does not mandate its own language.
>
>A better analogy in fact would be 'can we have built in support in IDEA for ATG Dynamo's .jhtml pages'
>
>I'm all for the IDEA guys improving their openAPI enough to allow random users to write plugins for their favourite time wasting 'cool' technology, but having it go into the core and offend everyone who wouldn't possibly care less seems a bit shortsighted, and is a sad indicator that three people yelling loudly enough can indeed determine the direction a product takes.
>
To say that it can be a plug-in is fine although not much of an argument in my opinion.
Sure I can agree with that... but that's just how things go with software development. What happened with AspectJ could have happened with many other things.
If you or anyone has good idea on what Intellij should spend their time on then by all means post it. I think that would be more constructive than repeating over and over that any form of AOP intetegration is not worth it.
But then that can be said about anything. It can be said about any vendor specific integration that anyone will talk about.
And discussing the subject could lead to creating a plugin... could lead to a different approach... or maybe to finding what OpenAPI channels are needed. Maybe there are enough similar AOP api's out there that a common AOP api is possible. I don't know...
I conceed AspectJ is not neccessarily the best API out ther for AOP. And as I have learned, through this forum, I have looked up other APIs that are out there.
I still maintain that AOP(not AspectJ specifically) is an interesting idea for integration into IDEA... plugin or core feature or something else.
And that's really what I would like to discuss. Could all the folks who have negative opinions about AspectJ say if it's only AspectJ they are against, or any AOP being a core feature of IDEA. What are the other APIs out there worth lookin at... I took a breif look at AspectWerkz and that looks like it has potential... and maybe it could be supported by a plug-in rather than full integration...
Florian
I think the problem at this point is there is no "standard" AOP API the could be used generically in an IDE. At some point, sepecific implementations would need to be written.
I'm not against AOP, in fact, I use it daily, just not at the AspectJ level of needing another compiler. But the types of AOP I use don't require the IDE to show many anything or do anything for me, even for debugging.
And as for your other points, that's all true. Sure, they could have not done a Weblogic integration, but that is a fairly large market and was their choice and I guess people are using it.
Even in 5.0, I know I'm happy they are doing both Subversion and Perforce since I happen to use them both. But again, these are larger markets ( in the Subversion area, that's possibly debatable ) than I think for a AOP solution since almost every developer has to deal with some sort of VCS.
Patrick
Like Patrick mentions, if I were to use AOP, I'd use the implementation in
Spring. I don't need extra compiler, I don't need my IDE to do anything
special, I just use it.
So I want to flip the question around, why don't you find an AOP impl which
does not require IDE specific integration and just use that? Why is it that
JetBrains needs to write SOME KIND of AOP impl to satisfy the few, when the
need of the many can be served already?
R
I don't absolutely want IntelliJ to do this for me. Just like anyone else, I am looking for making work-flow integration optimal.
I also want to debate it and here about others experience. And as of the last posts I am getting that.
Orthogonality is a big issue for me. And that's one thing AspectJ provides. And looking at other AOP frameworks I would want to have that. I am not sure I will get that with Spring framework... maybe with aspectWerks.
Florian
I don't understand why there is so much fear of aspect oriented development. It's just an other tool and has it purposes.
There is no fear of AOP; that's just something that its supporters say when they can't come up with good examples of its use.
And I would say that using it to instrument legacy code can be quite handy when you do not have the mandate to refactor it but have to work with it. Writing an aspect can also save you time when you have done all you can to find a bug and you are about to start peppering the code with System.out.println(). And not only does it save you time but you won't inadvertantly leave logging statements in the code after.
That's when I tend to use a debugger.
About debuggers... well you just can't do everything with debugging... ever tried to resolve threading problems with a debugger and have everything work fine when you debug but not when you run the app????!!!
Nope. But there are loads of GUI tools that let you watch object allocation and threads, without having to build aspects into your code (which can have exactly the same effect).
Well the comments by are certainly not trying to foster discussion.
I think the comments here are aimed at keeping JetBrains focussed on core stuff that IDEA needs. I would say the same thing if someone suggested adding ColdFusion support to IDEA, even though I am also a big fan of ColdFusion.
IDEA has always proven that a good interface to existing technologies can make a big difference towards user acceptance. I think the refactoring features demonstrate that very well.
Refactoring didn't need 'user acceptance'. Folk have been maintaining code since day one.
I think that this is what we, the ones who believe in AOP, feel. That a good editor for aspects will show-off what can be done with it, help ease the learning curve, and open the field to new things.
You don't even have any sort of standard way of doing this yet ... which particular implementation of Aspects should they support.
why do you or anyone else need to start calling people names when they disagree with you... forums are for discussion not for bloody fascism
The BileMan has a point though (not the brain-damage part obviously); aside from being of interest to only a minute fraction of the Java community, which implementation will they support?
Well... actually I have been researching this since everyone is so convinced that no one out there is supporting AOP! I have just discovered http://aopalliance.sourceforge.net . It's an API for standardisiing AOP support.
such products as Spring, AspectWerkz, Resin, Nanning and others seem to be basing their AOP efforts on this API.
Anybody know anything about it? Maybe this is what IDEA could provide support for?
Florian
ATG DSP rocks. :) JSP 2.0 is still a release or 2 behind. :(
Indeed.
JSP is built on technology that Sun licenses from ATG.
Well... actually I have been researching this since everyone is so convinced that no one out there is supporting AOP! I have just discovered http://aopalliance.sourceforge.net . It's an API for standardisiing AOP support.
Well, a handful of web pages, does not an alliance make ... :)
And who said no-one was supporting AOP? What we said was that the proportion of the Java Community that uses it, is a very tiny (if vocal) percentage.
AOP Alliance is pretty much a failure. Many of the frameworks support it, but it's pretty stagnant and the API doesn't seem to be moving forward very much.
Having said that, it's also a pure java API, so there's no integration to IDEA needed before you can start writing your aspects. Kinda worrying that the knee jerk reaction is to want it integrated to IDEA before even knowing what it is and how it works.
You're right in that this debate has proven useful, in that the non-AspectJers didn't do what we did last time and mostly stayed quiet (as you suggested, because they just didn't care about it, so they didn't feel they had anything to contribute to the discussion), with disasterous results. This time we're fighting fire with fire!
Note also that I said AspectJ, not AOP. I have no issue with a bunch of you clever AOP people getting together and wasting your own time writing a plugin, and then complaining to the IDEA people about holes in the openAPI that are making your job difficult. I just don't want to ever see aspectJ or AOP as part of the core product.
Florian, I don't fear AOP.
I just asked, what purposes, because I never saw a useful example yet
(beside plain logging or parameter checking).
Tom
Another use of AspectJ
I don't know how good this is, but I once thought about Code coverage tool with the help as AspectJ.
We insert Logging like statements in some predefined format, which gets saved into a global file (or data structure) and then there will be a tool to process it and tell about the statistics :)
Cheers
Anki.N