I've not seen anything about AspectJ being in IDEA 5, it's not on the features list.
Probably showing my ignorance here but what's the importance of AspectJ support anyway? I understand the value of AOP but isn't AspectJ simply the Eclipse proprietary implementation of AOP in Java?
If that is the case then why can't you just use AspectJ in IDEA like you can use any other API? For example I currently use things like Struts in my web applications and without any specific support for it within IDEA.
Again my apologies for my ignorance on the issue, I really don't know anything about AspectJ itself so I guess I'm kinda wondering what all the fuss is about (people have been requesting this for the last 2 major versions of IDEA and I've no idea why).
I haven't used AspectJ either, but to answer some of your questions:
Probably showing my ignorance here but what's the importance of AspectJ support anyway? I understand the value of AOP but isn't AspectJ simply the Eclipse proprietary implementation of AOP in Java?
No, AspectJ is not directly related to Eclipse. I think there's an Eclipse AspectJ plugin, though.
If that is the case then why can't you just use AspectJ in IDEA like you can use any other API? For example I currently use things like Struts in my web applications and without any specific support for it within IDEA.
AspectJ isn't an API, it's a language. You can certainly use AspectJ in IDEA now, but you don't get Java syntax highlighting in your AspectJ code, and refactorings don't work, and supposedly it's not very nice.
Thanks for the clarification Keith. It makes much more sense now, I think what was confusing me was my misperception that AspectJ was proprietary to Eclipse!!
There is some support for AspectJ in IDEA. Add -Didea.aspectj.support=enabled to lax.nl.java.option.additional in idea.lax and 'Aspect' will be available in the 'New' menu. I cannot tell you more then that as I did not have a chance to try AOP with IDEA yet.
For how much better with aspects can be see this: "Aspect-Oriented Design Pattern Implementations" http://www.cs.ubc.ca/~jan/AODPs/
I like the Observer implementation very much. However the Command pattern maybe already a kind of aspect oriented thing. It does not need aspect oriented support, just plain OOP is enough for the implementation of that Pattern.
For me the JBoss Implementation seems to be the most convenient. It does use a new language like AspectJ and JAsCo. It also supports Java5 annotations. As I know JAsCo also handles annotations. http://jboss.org/products/aop
I made some serious typing mistakes in my previous note. Here are the corrections:
For me the JBoss Implementation seems to be the most convenient, because it does NOT use a new language. AspectJ and JAsCo are extending the Java language. JBoss AOP is using configuration XML-files and/or special javadoc comments. It also supports Java5 annotations. As I know JAsCo also handles annotations.
I definitely would love to see an Aspect J plugin / integration -- currently everytime I generate my build.xml file, I have to manually add my aspect j compiles.
Perhaps Aspect J isn't the most widely used yet, because people haven't heard of it. But if you play with the Spring Framework --they have done their own AOP implementation...or vice versa, you can read how Aspect J can cut your 10,000 line code app to about 3,000.
I hate to say it, folks, but I am about to switch to Eclipse! In fact, the lack of support for AspectJ is the reason why my client's management has turned down IntelliJ in favor of Eclipse. I have been using IDEA for several years and am a die-hard fan, but this may be the one little thing that will kill it for me. We are seriously getting into AOP/AspectJ, and it looks like that's where the Java community may be headed these days - as more people grasp the idea and realize its value. Of course, moving from project to project, I see that many, if not most, programmers today still need to learn the basics of OOP and even proper structural programming. Who cares about aspects if people continue to mass-produce god-awful spaghetti code on a daily basis! :( What I have always admired about IntelliJ is that, in addition to making the development process easier, it educates programmers, promotes better practices, unintrusively guides you to do things right. Come on, JetBrains, give us some nice AOP support! :)
Perhaps, I am missing something, but I was not able to find a nice way to manage and compile aspects in IDEA. I have found some meantionings of a plug-in, but couldn't find it. Apparently, there's nothing out there that's stable. Is this true? If someone can provide any helpful info, I'd greatly appreciate it.
What I have always admired about IntelliJ is that, in additio n to making the development process easier, it educates programmers, promot es better practices, unintrusively guides you to do things right. Come on, JetBrains, give us some nice AOP support! :)
With aspects, you can code some code once - in a sngle place, and never worry about your developers screwing it up with their multiple "improvisations"... Instead, most people cut and paste the same try/catch blocks - or whatever - all over the place, hundreds of times... Aspects allow you to reduce the size of your code, eliminate duplicates, make it cleaner, and - the best part - consolidate the code that otherwise would be repeated many times in one place - outside your main code base. I hope the SIGN is that JetBrains is secretly preparing a killer feature that will blow Eclipse away... :)
With aspects, you can code some code once - in a sngle place, and never worry about your developers screwing it up with their multiple "improvisations"... Instead, most people cut and paste the same try/catch blocks - or whatever - all over the place, hundreds of times...
Personally, I'm of the opinion that this problem is better solved by the HR department ;)
Ciao, Gordon
-- Gordon Tyler (Software Developer) Quest Software <http://www.quest.com/> 260 King Street East, Toronto, Ontario M5A 4L5, Canada Voice: (416) 933-5046 | Fax: (416) 933-5001
>> With aspects, you can code some code >> once - in a sngle place, and never worry about your developers screwing >> it up with their multiple "improvisations"... Instead, most people cut >> and paste the same try/catch blocks - or whatever - all over the place, >> hundreds of times...
Personally, I'm of the opinion that this problem is better solved by the HR department ;)
What makes you think that your HR people are any more competent than your developers? :)
I'm sure they're competent in HR matters which is what it becomes when a dev manager informs them that a developer is not performing to standards and is to be fired.
And if you question the competency of your dev manager, you're screwed anyway so why bother with heavy-handed methodologies like aspects?
Ciao, Gordon
-- Gordon Tyler (Software Developer) Quest Software <http://www.quest.com/> 260 King Street East, Toronto, Ontario M5A 4L5, Canada Voice: (416) 933-5046 | Fax: (416) 933-5001
You must be living in a fantasy world, my friend. I remember, back in grad school, I read an article by the legendary computer scientist Dijkstra. The article ticked me off because, among other things, it claimed that 90%, or so, of all software engineers were incompetent software engineers. Since then, as a J2EE consultant, I have worked on many projects, and what I've seen is a sad picture. Perhaps it's different in Toronto, but here in the Boston area (supposedly, the most educated part of the US, with schools like MIT, etc.) there are quite a few folks who call themeselves Senior Software Engineers but still use a text editor to code, have no CS training, have very superficial understanding of objects, etc. Way too many "accidental" people came into this industry in the late 90's because of the dot-com boom. Companies were hiring just about anybody, the salaries were high. And the HR people were getting huge bonuses for bringing people onboard! That's the fact. Those accountants-turned-software-engineers, have put 5-7 years of "experience" on their resumes, and many of them have become dev managers. They can't tell a good developer from a bad one. All they care about is that the developer reports that the bug is fixed, so that they can report to their manager. After the market collapsed, the companies switched to another tactics: hiring the cheapest "junior" engineers, which produced the same effect: incompetence. I see this all the time, it's all the same - in small startups, or in large corporations. Well, that doesn't mean that there aren't great engineers out there, but the majority are mediocre. That said, Aspects is a great concept, and I am using aspects because it reduces the amount of work I have to do, it simplifies the code, and as the added bonus, it alows me to isolate some framework code even more - regardless of your team's experience it's always best to encapsulate any concept that varies (that's one of the most important tenets of OO, isn't it?) My $0.02. Cheers!
And so with your lack of faith on developer capacity, you are promoting the unmantainable dark magic of AOP that only a few wizards will be able to use effectively without making a big mess of things?
I can count on the fingers of one hand the number of developers that I would trust to use AOP - if I would see any real use for AOP beside logging and security ;)
No, I just have the good fortune to work with good poeple 8)
And the HR people were getting huge bonuses for bringing people onboard!
See, now there's the problem right there. What the hell does HR know about distinguishing a good developer from a bad developer?
Those accountants-turned-software-engineers, have put 5-7 years of "experience" on their resumes, and many of them have become dev managers. They can't tell a good developer from a bad one. All they care about is that the developer reports that the bug is fixed, so that they can report to their manager.
Like I said, if your dev manager is incompetent, you're screwed. Doubly so because the rest of the management team is most likely incompetent as well because they allowed this incompetent dev manager to be hired in the first place. Some will slip through the cracks but if the rest of your management team is on the ball, they'll notice and find a replacement.
That said, Aspects is a great concept, and I am using aspects because it reduces the amount of work I have to do, it simplifies the code, and as the added bonus, it alows me to isolate some framework code even more - regardless of your team's experience it's always best to encapsulate any concept that varies (that's one of the most important tenets of OO, isn't it?)
And like Carlos said, Aspects are "unmaintenable dark magic". Some piece code in some godforsaken depths of your codebase has a direct impact on the behaviour of your code AND YOU DON'T KNOW unless you were specifically told about it or designed it that way yourself. Aspects are invisible and I don't like invisible code. I firmly believe in encapsulation and abstraction but as far as I'm concerned, Aspects are not the way to do it. I am in the "explicit is better than implicit" camp.
Besides, have you ever looked at a decompiled class that was munged by AspectJ? The code bloat is truly awful.
But I don't think we're going to change each other's minds on this matter ;)
Ciao, Gordon
-- Gordon Tyler (Software Developer) Quest Software <http://www.quest.com/> 260 King Street East, Toronto, Ontario M5A 4L5, Canada Voice: (416) 933-5046 | Fax: (416) 933-5001
I used to work landscaping back through high school. Like SE, there were those who understood how machines operated, and those who did not. Consequently, those who did not were assigned simple chores, like raking, or potentially even push-mowing. Those who did understand how "things worked" used the larger machines, and were correspondingly more productive. Point being, if you have intelligent personnel, I think AspectJ is a powerful and time-saving tool. We've all worked with folks who don't even understand basic OO concepts (e.g. "why use get/sets in an interface when it's quicker just to access member variables?"); handing AspectJ to these types is a horrifying thought to me. Typically in these cases it becomes exclusively a source of rework and error. By the same token, those who understand truly the notion of clear multi-dimensional separation of concerns may accelerate their work tremendously using AOP.
Seems to me that both sides in this thread argue to this point. If you have the team, go for it. If not, hell no don't touch the stuff.
>> And like Carlos said, Aspects are "unmaintenable dark magic". Some piece code in some godforsaken depths of your codebase has a direct impact on the behaviour of your code AND YOU DON'T KNOW unless you were specifically told about it or designed it that way yourself. Aspects are invisible and I don't like invisible code.
That's the whole point of good IDE - to uncover that 'magic' for you, to see where the aspects are used, ... And this is why this topic has been raised - to bring back even better AspectJ support. And NOT for you and V. to get into rampage about AOP.
That's the whole point of good IDE - to uncover that 'magic' for you, to see where the aspects are used, ... And this is why this topic has been raised - to bring back even better AspectJ support. And NOT for you and V. to get into rampage about AOP.
Exactly. So what is the answer? Is AspectJ going to make it into IDEA at some point or not?
Keith Lancaster Noblestar -
Dobie's Dogma: If you are not thoroughly confused, you have not been thoroughly informed.
>>>handing AspectJ to these types is a horrifying thought to me. Typically in these cases it becomes exclusively a source of rework and error.
See, that's the point: you don't hand the aspects to such people. The same way you wouldn't want them to tinker with your framework/base classes. Your "framework" team/person should have ownership of the aspects, and the rest of the team shouldn't even be aware of that.
Anyway, I think many of us would like to see IntelliJ provide good support for aspects. Even if it's there, it wouldn't hurt folks like Gordon in any way, but many people would benefit from that. I rarely work with Swing, so I don't really care whether IntelliJ provides nice GUI-building tools. But I don't go around saying IntelliJ doesn't need that. :)
Well, based on the JetBrains' silence, I assume it's not going to happen any time soon.
>>>Like I said, if your dev manager is incompetent, you're screwed. Doubly so because the rest of the management team is most likely incompetent as well because they allowed this incompetent dev manager to be hired in the first place. Some will slip through the cracks but if the rest of your management team is on the ball, they'll notice and find a replacement.
Dude, it's the companies that get screwed, unfortunately... I just do my job the best I can, and usually am the one who ends up laughing on the way to the bank... :) You are lucky if you work in a perfect shop, but most teams out there have weak links... I usually try to design software in a way that any complex/repeating constructs are isolated, abstracted from the majority of the developers. (I am sure you do the same.) That certainly helps maintenance tremendously. Aspects - in many cases - do just that. In some cases they are not appropriate, but no one says that you should use them all the time.
>>>That's the whole point of good IDE - to uncover that 'magic' for you, to see where the aspects are used, ... And this is why this topic has been raised - to bring back even better AspectJ support. And NOT for you and V. to get into rampage about AOP.
No one gets into rampage... I think this discussion is quite relevant, and, perhaps, would prompt someone at JetBrains to at least give us a straight answer. So far, they have completely ignored this thread...
All thing indicate to v5.0, since they are awfully quiet about it in EAP.
Any other info?
Rgds, Ales
I've not seen anything about AspectJ being in IDEA 5, it's not on the features list.
Probably showing my ignorance here but what's the importance of AspectJ support anyway? I understand the value of AOP but isn't AspectJ simply the Eclipse proprietary implementation of AOP in Java?
If that is the case then why can't you just use AspectJ in IDEA like you can use any other API? For example I currently use things like Struts in my web applications and without any specific support for it within IDEA.
Again my apologies for my ignorance on the issue, I really don't know anything about AspectJ itself so I guess I'm kinda wondering what all the fuss is about (people have been requesting this for the last 2 major versions of IDEA and I've no idea why).
I haven't used AspectJ either, but to answer some of your questions:
No, AspectJ is not directly related to Eclipse. I think there's an Eclipse AspectJ plugin, though.
AspectJ isn't an API, it's a language. You can certainly use AspectJ in IDEA now, but you don't get Java syntax highlighting in your AspectJ code, and refactorings don't work, and supposedly it's not very nice.
-Keith
Thanks for the clarification Keith. It makes much more sense now, I think what was confusing me was my misperception that AspectJ was proprietary to Eclipse!!
Thanks again,
Rob :)
There is some support for AspectJ in IDEA.
Add -Didea.aspectj.support=enabled to lax.nl.java.option.additional in idea.lax and 'Aspect' will be available in the 'New' menu. I cannot tell you more then that as I did not have a chance to try AOP with IDEA yet.
For how much better with aspects can be see this:
"Aspect-Oriented Design Pattern Implementations"
http://www.cs.ubc.ca/~jan/AODPs/
I like the Observer implementation very much.
However the Command pattern maybe already a kind of aspect oriented thing. It does not need aspect oriented support, just plain OOP is enough for the implementation of that Pattern.
There are some more what aspects can do info here:
http://docs.jboss.org/aop/aspect-library/
For me the JBoss Implementation seems to be the most convenient. It does use a new language like AspectJ
and JAsCo. It also supports Java5 annotations.
As I know JAsCo also handles annotations.
http://jboss.org/products/aop
When you want to start to use aspects, probably you will need a convenient tool to use it:
http://docs.jboss.org/jbosside/jboss-ide-aop-demo/
I made some serious typing mistakes in my previous note.
Here are the corrections:
For me the JBoss Implementation seems to be the most convenient, because it does NOT use a new language. AspectJ
and JAsCo are extending the Java language. JBoss AOP is using configuration XML-files and/or special javadoc comments. It also supports Java5 annotations.
As I know JAsCo also handles annotations.
I definitely would love to see an Aspect J plugin / integration -- currently everytime I generate my build.xml file, I have to manually add my aspect j compiles.
Perhaps Aspect J isn't the most widely used yet, because people haven't heard of it. But if you play with the Spring Framework --they have done their own AOP implementation...or vice versa, you can read how Aspect J can cut your 10,000 line code app to about 3,000.
I hate to say it, folks, but I am about to switch to Eclipse! In fact, the lack of support for AspectJ is the reason why my client's management has turned down IntelliJ in favor of Eclipse. I have been using IDEA for several years and am a die-hard fan, but this may be the one little thing that will kill it for me. We are seriously getting into AOP/AspectJ, and it looks like that's where the Java community may be headed these days - as more people grasp the idea and realize its value. Of course, moving from project to project, I see that many, if not most, programmers today still need to learn the basics of OOP and even proper structural programming. Who cares about aspects if people continue to mass-produce god-awful spaghetti code on a daily basis! :( What I have always admired about IntelliJ is that, in addition to making the development process easier, it educates programmers, promotes better practices, unintrusively guides you to do things right. Come on, JetBrains, give us some nice AOP support! :)
Perhaps, I am missing something, but I was not able to find a nice way to manage and compile aspects in IDEA. I have found some meantionings of a plug-in, but couldn't find it. Apparently, there's nothing out there that's stable. Is this true? If someone can provide any helpful info, I'd greatly appreciate it.
Maybe they're giving you a sign. :)
Haha! You're a funny man... :)))
With aspects, you can code some code once - in a sngle place, and never worry about your developers screwing it up with their multiple "improvisations"... Instead, most people cut and paste the same try/catch blocks - or whatever - all over the place, hundreds of times... Aspects allow you to reduce the size of your code, eliminate duplicates, make it cleaner, and - the best part - consolidate the code that otherwise would be repeated many times in one place - outside your main code base. I hope the SIGN is that JetBrains is secretly preparing a killer feature that will blow Eclipse away... :)
Constantine Vasilyev wrote:
Personally, I'm of the opinion that this problem is better solved by the
HR department ;)
Ciao,
Gordon
--
Gordon Tyler (Software Developer)
Quest Software <http://www.quest.com/>
260 King Street East, Toronto, Ontario M5A 4L5, Canada
Voice: (416) 933-5046 | Fax: (416) 933-5001
hahaha. nice.
Gordon Tyler wrote:
>> With aspects, you can code some code
>> once - in a sngle place, and never worry about your developers screwing
>> it up with their multiple "improvisations"... Instead, most people cut
>> and paste the same try/catch blocks - or whatever - all over the place,
>> hundreds of times...
What makes you think that your HR people are any more competent than your developers? :)
Constantine Vasilyev wrote:
I'm sure they're competent in HR matters which is what it becomes when a
dev manager informs them that a developer is not performing to standards
and is to be fired.
And if you question the competency of your dev manager, you're screwed
anyway so why bother with heavy-handed methodologies like aspects?
Ciao,
Gordon
--
Gordon Tyler (Software Developer)
Quest Software <http://www.quest.com/>
260 King Street East, Toronto, Ontario M5A 4L5, Canada
Voice: (416) 933-5046 | Fax: (416) 933-5001
You must be living in a fantasy world, my friend. I remember, back in grad school, I read an article by the legendary computer scientist Dijkstra. The article ticked me off because, among other things, it claimed that 90%, or so, of all software engineers were incompetent software engineers. Since then, as a J2EE consultant, I have worked on many projects, and what I've seen is a sad picture. Perhaps it's different in Toronto, but here in the Boston area (supposedly, the most educated part of the US, with schools like MIT, etc.) there are quite a few folks who call themeselves Senior Software Engineers but still use a text editor to code, have no CS training, have very superficial understanding of objects, etc. Way too many "accidental" people came into this industry in the late 90's because of the dot-com boom. Companies were hiring just about anybody, the salaries were high. And the HR people were getting huge bonuses for bringing people onboard! That's the fact. Those accountants-turned-software-engineers, have put 5-7 years of "experience" on their resumes, and many of them have become dev managers. They can't tell a good developer from a bad one. All they care about is that the developer reports that the bug is fixed, so that they can report to their manager. After the market collapsed, the companies switched to another tactics: hiring the cheapest "junior" engineers, which produced the same effect: incompetence. I see this all the time, it's all the same - in small startups, or in large corporations. Well, that doesn't mean that there aren't great engineers out there, but the majority are mediocre. That said, Aspects is a great concept, and I am using aspects because it reduces the amount of work I have to do, it simplifies the code, and as the added bonus, it alows me to isolate some framework code even more - regardless of your team's experience it's always best to encapsulate any concept that varies (that's one of the most important tenets of OO, isn't it?) My $0.02.
Cheers!
And so with your lack of faith on developer capacity, you are promoting the
unmantainable dark magic of AOP that only a few wizards will be able to use
effectively without making a big mess of things?
I can count on the fingers of one hand the number of developers that I would
trust to use AOP - if I would see any real use for AOP beside logging and
security ;)
Constantine Vasilyev wrote:
No, I just have the good fortune to work with good poeple 8)
See, now there's the problem right there. What the hell does HR know
about distinguishing a good developer from a bad developer?
Like I said, if your dev manager is incompetent, you're screwed. Doubly
so because the rest of the management team is most likely incompetent as
well because they allowed this incompetent dev manager to be hired in
the first place. Some will slip through the cracks but if the rest of
your management team is on the ball, they'll notice and find a replacement.
And like Carlos said, Aspects are "unmaintenable dark magic". Some piece
code in some godforsaken depths of your codebase has a direct impact on
the behaviour of your code AND YOU DON'T KNOW unless you were
specifically told about it or designed it that way yourself. Aspects are
invisible and I don't like invisible code. I firmly believe in
encapsulation and abstraction but as far as I'm concerned, Aspects are
not the way to do it. I am in the "explicit is better than implicit" camp.
Besides, have you ever looked at a decompiled class that was munged by
AspectJ? The code bloat is truly awful.
But I don't think we're going to change each other's minds on this matter ;)
Ciao,
Gordon
--
Gordon Tyler (Software Developer)
Quest Software <http://www.quest.com/>
260 King Street East, Toronto, Ontario M5A 4L5, Canada
Voice: (416) 933-5046 | Fax: (416) 933-5001
Couple of good posts on this issue, I think.
I used to work landscaping back through high school. Like SE, there were those who understood how
machines operated, and those who did not. Consequently, those who did not were assigned simple
chores, like raking, or potentially even push-mowing. Those who did understand how "things worked"
used the larger machines, and were correspondingly more productive. Point being, if you have
intelligent personnel, I think AspectJ is a powerful and time-saving tool. We've all worked with
folks who don't even understand basic OO concepts (e.g. "why use get/sets in an interface when it's
quicker just to access member variables?"); handing AspectJ to these types is a horrifying thought
to me. Typically in these cases it becomes exclusively a source of rework and error. By the same
token, those who understand truly the notion of clear multi-dimensional separation of concerns may
accelerate their work tremendously using AOP.
Seems to me that both sides in this thread argue to this point. If you have the team, go for it.
If not, hell no don't touch the stuff.
-Fred
>> And like Carlos said, Aspects are "unmaintenable dark magic". Some piece
code in some godforsaken depths of your codebase has a direct impact on
the behaviour of your code AND YOU DON'T KNOW unless you were
specifically told about it or designed it that way yourself. Aspects are
invisible and I don't like invisible code.
That's the whole point of good IDE - to uncover that 'magic' for you, to see where the aspects are used, ... And this is why this topic has been raised - to bring back even better AspectJ support. And NOT for you and V. to get into rampage about AOP.
Exactly. So what is the answer? Is AspectJ going to make it into IDEA at
some point or not?
Keith Lancaster
Noblestar
-
Dobie's Dogma:
If you are not thoroughly confused, you have not been thoroughly informed.
>>>handing AspectJ to these types is a horrifying thought
to me. Typically in these cases it becomes exclusively a source of rework and error.
See, that's the point: you don't hand the aspects to such people. The same way you wouldn't want them to tinker with your framework/base classes. Your "framework" team/person should have ownership of the aspects, and the rest of the team shouldn't even be aware of that.
Anyway, I think many of us would like to see IntelliJ provide good support for aspects. Even if it's there, it wouldn't hurt folks like Gordon in any way, but many people would benefit from that. I rarely work with Swing, so I don't really care whether IntelliJ provides nice GUI-building tools. But I don't go around saying IntelliJ doesn't need that. :)
Well, based on the JetBrains' silence, I assume it's not going to happen any time soon.
>>>Like I said, if your dev manager is incompetent, you're screwed. Doubly
so because the rest of the management team is most likely incompetent as
well because they allowed this incompetent dev manager to be hired in
the first place. Some will slip through the cracks but if the rest of
your management team is on the ball, they'll notice and find a replacement.
Dude, it's the companies that get screwed, unfortunately... I just do my job the best I can, and usually am the one who ends up laughing on the way to the bank... :) You are lucky if you work in a perfect shop, but most teams out there have weak links... I usually try to design software in a way that any complex/repeating constructs are isolated, abstracted from the majority of the developers. (I am sure you do the same.) That certainly helps maintenance tremendously. Aspects - in many cases - do just that. In some cases they are not appropriate, but no one says that you should use them all the time.
>>>That's the whole point of good IDE - to uncover that 'magic' for you, to see where the aspects are used, ... And this is why this topic has been raised - to bring back even better AspectJ support. And NOT for you and V. to get into rampage about AOP.
No one gets into rampage... I think this discussion is quite relevant, and, perhaps, would prompt someone at JetBrains to at least give us a straight answer. So far, they have completely ignored this thread...