Develop with Pleasure: The Next Big Thing

Well, we're getting on toward release time for 7.0, and naturally thoughts turn to roadmap possibilities for the 8.0 release. Frankly, I'm a bit stumped. IDEA 7.0 adds support for Spring, Hibernate, Maven, TestNG, Ruby, Rails, Groovy, Grails, Web Services, and probably more stuff I'm forgetting. At this point, there are actually very few technologies I use daily which IDEA doesn't support, and support about as well as I'm able to envision. In the spirit of John Steelman's previous threads the little things that could be done to improve the IDEA, I figured I'd launch a thread to see what people think are the large functional areas missing from IDEA.

Ground rules:

1) Suggestions must be something large enough to appear as a line item on the IDEA 8.0 roadmap.

2) Ideally, suggestions should be large enough that someone might consider driving a purchasing decision based on the decision. "Support technology X" works better if there's some indication of there actually being a market for technology X. Scala and AspectJ might be nice, and undoubtedly technologically exciting, but the user communities are currently pretty small.

3) Suggestions that performance/stability/memory usage should be the main focus of the next release belong in some other thread.

4) Most important, suggestions should be aid the goal "Develop with Pleasure", which is to say that they should be pitched toward aiding developers (as opposed to managers, QA, etc) with pleasurably performing the tasks they need to do to get their job done.

I'll start: Integrated task management, including adapters for all of the major issue tracking systems, Mylyn-like context management, clean integration with IDEA change lists, and probably some TeamCity extensions for release management. Mylyn (previously Mylar) is the only bit of Eclipse technology I've ever been jealous of. http://www.eclipse.org/mylyn/

--Dave Griffith

113 comments
Comment actions Permalink

I'd suggest two things:
1. JavaScript frameworks support (prototype-style classes, mootools-style classes, dojo, maybe yui, maybe ext)
2. Add common refactorings to openAPI, so that custom languages could provide not only rename and introduce variable, but more complex ones. And add them it to Ruby, Groovy, Javascript..

0
Comment actions Permalink

Hello Jay,

I'd suggest two things:

1. JavaScript frameworks support (prototype-style classes,
mootools-style classes, dojo, maybe yui, maybe ext)

2. Add common refactorings to openAPI, so that custom languages could
provide not only rename and introduce variable, but more complex ones.
And add them it to Ruby, Groovy, Javascript..


These aren't really big things. :)

JavaScript frameworks are basically supported at the rate of someone filing
JIRA issues requesting specific features to support. (As far as I know, prototype-style
classes are already supported.)

Refactoring OpenAPI is currently mostly driven by the requirements of the
language plugins we are developing. (For example, Groovy developers wanted
to have Inline, so Inline is pluggable in 7.0.) We find that this works better
than adding speculative APIs which are not initially used by anything, because
such APIs can turn out to be unsuitable for any actual use.

So, yes, we will definitely have more of each of these items in the next
release.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

Hello Dmitry,

Refactoring OpenAPI is currently mostly driven by the requirements of
the language plugins we are developing. (For example, Groovy developers
wanted to have Inline, so Inline is pluggable in 7.0.) We find that this
works better than adding speculative APIs which are not initially used
by anything, because such APIs can turn out to be unsuitable for any
actual use.


The worst API is an API that doesn't exist. To be honest, I don't understand what's the
point in preventing people to plug into actions that do already work for java code, just
because there's no JB-plugin that needs it.

All the popular refactorings could have been easily made available like
RefactoringSupportProvider#getIntroduceVariableHandler - maybe not at such high level as
the new InlineHandler - but with virtually no risk of creating an API that's "unsuitable".

http://www.jetbrains.net/jira/browse/IDEADEV-10476

Sascha

0
Comment actions Permalink

Hi,

My modest wish list includes:
Support for C++ (eclipse has it).
Support for Velocity templates

Thanks,
Erez.

0
Comment actions Permalink

Hello enahir,

My modest wish list includes:
Support for C++ (eclipse has it).


This is out of scope for the IntelliJ IDEA project, and we don't have any
plans to develop such a project at JetBrains. There's a third-party C++ support
plugin available on plugins.intellij.net.

Support for Velocity templates


This is very likely to be implemented in 8.0.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Avatar
Eugene Vigdorchik
Comment actions Permalink

The problem with opening handlers is that it is too high-level, thus it is inappropriate for refactoring cross-language projects, i,e, when the target is in one language and the reference is in the other. If you look at API for inline, it does account for this.

Eugene.

0
Comment actions Permalink

Dave Griffith wrote:

I'll start: Integrated task management, including adapters for all of
the major issue tracking systems, Mylyn-like context management,
clean integration with IDEA change lists, and probably some TeamCity


Time to start giving some love to my JIRA browser plugin - I think
theres also a few other task tracking/todo list plugins already that
could probably pull together for somethng fancy... maybe.

0
Comment actions Permalink

Dave Griffith wrote:

1) Suggestions must be something large enough to appear as a line
item on the IDEA 8.0 roadmap.


1. Open Code Coverage data to inspections - I'd love to run some tests,
navigate to some uncovered code and have IDEA subtly give me a lightbulb
to "Add test for method #xxxxx". Or have inspection reports highlight
code thats not covered by tests.

I'm sure there could be alot of things we could come up with if the
coverage data was accessible...

0
Comment actions Permalink

Mark Derricutt wrote:

Dave Griffith wrote:

>> I'll start: Integrated task management, including adapters for all of
>> the major issue tracking systems, Mylyn-like context management,
>> clean integration with IDEA change lists, and probably some TeamCity

Another one - distributed version control systems.

Theres the Mercurial plugin being developed already, taking that onboard
and making it a first class VCS module would kick arse.

0
Comment actions Permalink

Hello Eugene,

Inline may be a special case, but for the vast majority of cases, the issue of
cross-language references just doesn't matter. My point is that the API should have been
made consistent in the moment Introduce Variable has been added, which could have done
with virtually no effort, but would have allowed to plug into the standard-refactorings in
a proper way.

And there's also nothing that prevents refining the APIs when needed. IDEA-APIs break
between every release, knowingly or unknowingly, so until a refined high-level API is
needed, there would at least be some API.

I even doubt I could now use the InlineHandler API for XSLT because I don't have control
over the hosting XML-Language's refactoring support. Which makes the new high-level API in
fact less powerful, and that's what I'd call an unsuitable API (even if I have to admit
that this is a rare case too).

I'll wait and see what IDEA 8.0 will bring... ;)

Sascha

0
Comment actions Permalink

Hello Eugene.

I don't clearly understand why some refactoring handlers could be inappropriate for cross-language projects.
The thing that i am mostly conserned about is simply some place for refactorings. I remember i was trying to add introduce variable in IDEA 5.1 - and i was a bit confused by the fact that it seemed like i needed a new action with the same CtrlAltV shortcut which i would place somewhere in menu with title "my custom language refactorings". To me refactoring is not dependent on the language.

ps. Sascha, thanks for support

0
Comment actions Permalink

>> Support for Velocity templates

>This is very likely to be implemented in 8.0.

Tapestry? Freemarker? Pure curiousity. I've got no particular dog in this fight.

--Dave Griffith

0
Comment actions Permalink

Theres the Mercurial plugin being developed already, taking that onboard
and making it a first class VCS module would kick arse.


If you find a 100%-Java implementation, that would be cooool.

0
Comment actions Permalink

Hello Mark,

Another one - distributed version control systems.

Theres the Mercurial plugin being developed already, taking that
onboard and making it a first class VCS module would kick arse.


I wonder if there's any data available regarding the usage of distributed
VCS systems in the enterprise. So far it looks like the DVCS adoption is
coming quite slowly (for example, people kept on talking about the Mercurial
repository for OpenJDK, and it's still nowhere to be seen).

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

Hello Dave,

>>> Support for Velocity templates
>>>
>> This is very likely to be implemented in 8.0.
>>

Tapestry? Freemarker? Pure curiousity. I've got no particular dog in
this fight.


Freemarker, yes; Tapestry, don't know. With the usual amount of disclaimers
that apply. :)

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

Hello Mark,

1. Open Code Coverage data to inspections - I'd love to run some
tests, navigate to some uncovered code and have IDEA subtly give me a
lightbulb to "Add test for method #xxxxx". Or have inspection reports
highlight code thats not covered by tests.

I'm sure there could be alot of things we could come up with if the
coverage data was accessible...


Well, it is accessible. It's even in the OpenAPI. It even has some javadocs.
See the CoverageDataManager class.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

Hello Dmitry,

>>>> Support for Velocity templates
>>>>
>>> This is very likely to be implemented in 8.0.
>>>
>> Tapestry? Freemarker? Pure curiousity. I've got no particular dog
>> in this fight.
>>

Freemarker, yes; Tapestry, don't know. With the usual amount of
disclaimers that apply. :)


IIRC, during start of Selena EAP there was a plan to use the RHTML work from
the Ruby plugin to build a (sample) Velocity plugin.
Did something come out of this?

-tt


0
Comment actions Permalink

Hello Taras,

>> Freemarker, yes; Tapestry, don't know. With the usual amount of
>> disclaimers that apply. :)
>>

IIRC, during start of Selena EAP there was a plan to use the RHTML
work from the Ruby plugin to build a (sample) Velocity plugin.
Did something come out of this?


No, as far as I know.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

Things I would love to see:

1) Ant debugging like netbeans has (see http://ant.netbeans.org/debugger.html)

2) Similarly: XSLT debugging

3) Editor groups (see http://www.jetbrains.net/jira/browse/IDEA-12130); ability to group the currently open editors into separate tabs, either by filetype, by VCS status, by module, ...

0
Comment actions Permalink

Dmitry Jemerov wrote:

I wonder if there's any data available regarding the usage of
distributed VCS systems in the enterprise. So far it looks like the DVCS
adoption is coming quite slowly (for example, people kept on talking
about the Mercurial repository for OpenJDK, and it's still nowhere to be
seen).


Kelly O'Hair's been publically blogging lately about the transition to
mercurial:

http://weblogs.java.net/blog/kellyohair/

I have been seeing more and more places adopting mercurial (although I
dont have references off hand).


0
Comment actions Permalink

Dmitry Jemerov wrote:

Well, it is accessible. It's even in the OpenAPI. It even has some
javadocs.
See the CoverageDataManager class.


Mmm when did that come in? I wonder if just didn't get me access to the
data I wanted (easily) when I last looked at that.

Hmmm - time to go reading ;)




0
Comment actions Permalink

Hello Jens,

2) Similarly: XSLT debugging


That's not too far away actually ;)

Sascha

0
Comment actions Permalink

Really nobody interested? Or do your Website designers already have their
own tools? We don't need Velocity or FreeMarker templating any more after
switching to Wicket.

0
Comment actions Permalink

Jay wrote:

To me refactoring is not dependent on the language.


There's much more in refactorings than it seems too... They care about
control flow, constant evaluation, data flow calculations, variable
aliasing, exception handling, etc. And all these are fundamentally
different in different languages. It really seems that creating
abstractions of this level might be impractical. That's why we're still
looking for problem solution and try to generify existing refactorings.

0
Comment actions Permalink

The worst API is an API that doesn't exist. To be honest, I don't
understand what's the point in preventing people to plug into actions
that do already work for java code, just because there's no JB-plugin
that needs it.


This sounds like a "Worst feature is a feature that doesn't exist. Give
us FEATURES!"...

We do try to add API whenever possible. We simply can't add api to all
refactorings at once due to their number and complexity.

0
Comment actions Permalink

IIRC, during start of Selena EAP there was a plan to use the RHTML work
from the Ruby plugin to build a (sample) Velocity plugin.
Did something come out of this?


You slightly missed the point. We reimplemented JSP and used RHTML as a
testbed for new API, which will (might/can) be used for Freemarker
implementation.

0
Comment actions Permalink

Hello Mike,

>> The worst API is an API that doesn't exist. To be honest, I don't
>> understand what's the point in preventing people to plug into actions
>> that do already work for java code, just because there's no
>> JB-plugin that needs it.


This sounds like a "Worst feature is a feature that doesn't exist. Give
us FEATURES!"...


Sorry, that's absolutely not what I said. It's about the difference of having no simple API at all
vs. an API that fits any possible future requirement but doesn't exist.

Please see the issue link I posted. I still haven't seen a good reason yet why the
RefactoringSupport interface doesn't contain methods that return a simple RefactoringActionHandler
for the most common refactorings. That's not blindly calling for vague features, but a very clearly
formulated request.

We do try to add API whenever possible. We simply can't add api to all
refactorings at once due to their number and complexity.


Well, adding "@Nullable RefactoringActionHandler getExtractMethodHandler()" and some of its
relatives is hardly a high number nor an extreme complexity.

I don't like to argue about this and I really appreciate that you strive to provide the best
possible API, but I honestly don't understand this policy that has now prevented custom languages to
properly implement e.g. an Extract Method feature since the Language API was introduced over two
years ago.

Sascha

0
Comment actions Permalink

If you really want to know: no, not really.

I can imagine that creating a WYSIWYG-HTML will take a really long time, and the added value (for me) will be minimum. I see IntelliJ primarily as Java IDE, not an all-in-one tool Support for Ruby and Groovy are some nice extra's, but I don't like to see IntelliJ becoming the next Frontpage.

Frontpage is a nice tool, Dreamweaver is also pretty nice: you are probably better of using them instead.

I'd much rather see integrated profiling, better code coverage support, and Java framework support (Terracotta/Gigaspaces/Guice/Wicket) than things like this.

0
Comment actions Permalink

Hello Erik,

I'd much rather see integrated profiling, better code coverage
support,


What exactly would you like to see improved?

and Java framework support
(Terracotta/Gigaspaces/Guice/Wicket) than things like this.


Have you tried the existing plugins for Guice and Wicket? If yes, do they
suit your needs?

--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0

Please sign in to leave a comment.