Your Five Favourites Features For 4.0

Macros

Highlight methods which don't have tests, show report of test coverage
similar to that of Clover.

Auto-run tests in background every N minutes and have it show status through
red/green bar in status bar.

Integrated tracker
Integrated task/story list

-1 for GUI builder the way that others have done it. Might be cool to have
something that shows you a real-time view, maybe in the bottom half of a
splitpane, of what your panel looks like while you modify it. Would prefer
it done as a plugin through.

-1 for read/writeUML support, +1 for read-only UML view of classes.



"Alain Ravet" <alain.ravet.list@wanadoo.be> wrote in message
news:as5dj8$g84$1@is.intellij.net...

What would change your java programmer's life, and how can IDEA make it
happen?

>

With 1110 features requests currently open/submitted in the tracker, the
voting system won't do any good at hinting IDEA people about what we
wish/need.

>
>
>

What does your wish list look like. No, what are the 5 first items on
your wish list?

>

Don't think too much, don't search : what do you miss today?
(Keep the lists short : no need the replicate the features tracker!)

>

Alain Ravet

>

There has been an interesting thread on extension of JUnit and new
integration with IDE.
Erik Gamma and Kent Beck are at it again in Eclipse to automatically run the
test right after compilation and provide feedback the test failures in the
same way as compilation errors. Very nice. Obviously we need to be able to
"decorate" the builtin representation to get the same nice feedback Eclipse
has (red X on package the includes directly or indirectly an error). The
other ideas are even better:
1) Automatic detection of impacted tests to be run
2) Highlighting of production code not tested by the suite
3) Prevent adding a production method w/o first being referenced by a test
(Michael Features not here)
4) Yellow bar for tests that you temporary disable (easy in .NET which has
Attributes support. I guess we could use XDoclet for this until JSR175 is
released).

Here is an extract:

KB(Kent Beck):

KB> When you check in, though, the system should be in a known

state.

If all
KB> the tests don't run, I have an unknown amount of work to make

them =

>

all
KB> run. If they all run, I know how much work I have to do to make
them
KB> run. I wouldn't check in if my code didn't compile, any more

than I=

>

KB> would check in with a broken tests. Erich and I are working on

an

KB> experimental JUnit plugin that runs tests after every compile

and

KB> reports the errors using the same mechanisms in Eclipse that

are

used to
KB> report compile errors. I don't have enough experience with it

yet

to
KB> reach any conclusions, but just the idea that the tests were

peers =

>

of
KB> the compiler was a shift of metaphor for me.

>

Tell you what I'd like to experiment with.. every time your bar

goes

green the IDE checks in your changes transparently. At any time

you

can revert to the previous greenbar. Greenbars are marked by

time,

date, and the names of new tests since the last greenbar. On a

team

projects you can configure the IDE to give you the option to

refresh

your sandbox whenever you greenbar and something has changed.

>
>

Sounds interesting.

>

Maybe the greenbars could also show deleted tests since the last
greenbar - this would help identify possible commented out tests.

>

I like the idea of the tests and the compiler being peers - what if

we

extend this and have the IDE report lines of production code that are
not used by the associated JUnit test and reports them as errors the
same same way. This would help enforce the TDD approach of only

writing

code to pass a failing test and it could also be used when writing

unit

tests for code that was not developed TDD.

>

What a radical idea! [grin]. The only difficulty I have with this is
that c=
overage analyzers take time to run. The one I use (pycover) takes
about four=
times as long as just running the unit tests by themselves

I deliberately didn't use the word coverage analyzer in my description
as what I was proposing was not intending to be a replacement for a
proper coverage analyzer. It was just intending to show the statement
coverage of the JUnit tests against the production code to highlight
that there were statements that had been written in the production code
that were not fixing a broken test. Its intention was not to be a
proper coverage analyzer that could identify the deficiencies of the
test suite.

With regard to the speed aspect I was hoping that the plugin would be
working in the background at all times only performing the JUnit tests
that are impacted by test and/or code changes. Essentially it would be
incremental JUnit testing similar to the current Eclipse incremental
compile.

Here is what I see my session would be like:

1. I have a Incremental JUnit plugin running - Its external interface
is a single bar that is at the top of my screen. If I click in the bar
it will run all my JUnit tests and I see the bar moving from left to
right as the tests are run. The moving bar will show green until a test
fails and then it will be all red from there on. The actual reporting
of failed tests will be in the same place that compile errors are
shown. Lets assume I have five successful tests already in place and I
have a green bar.

2. I add a new test. The plugin sees it is new and automatically adjust
the bar to show that there are tests that have not run (not too sure
what this would be). Then it attempts to run these outstanding tests.
When they complete the bar automatically will show the status - in this
case the test fails and the bar goes red. I can hover over the bar and
see that 5 tests passed and 1 failed. My IDE is also reporting the
failed test the same way it reports a compile failure.

3. I now switch across to the production code and change code in a
method to fix the test. The plugin is able to know what tests are
broken and attempts to run the broken tests. It also knows which tests
will be affected by changes to this code and marks those to be run as
well - this all happens automatically in the background. The broken
test now passes and the bar is green. The plugin at this stage
transparently checks all code into the local repository as it has
sensed that the code has changed and we have a new green bar.

4. I now think about what I want to do next - instead of writing a test
I add a new method in the production code which has not been exercised
by the JUnit tests. The plugin (using its magical powers derived from
its statement coverage) knows there is not a test that exercises this
method and set the bar red again. It reports these lines as with an
untested error which is similar to compile errors. Note that the red
bar in this case not for a broken test but for untested production
code. If I try to check this code in then the plugin will not allow it
unless I remove the untested code or drop the plugin to a less strict
level (maybe legacy level).

I would at least be interested in trying an IDE like that.

Ross

See also
http://www.intellij.net/tracker/idea/viewSCR?publicId=6014

Tom

Don't you just love it when managers make coding decisions.

It brings back memories of when I was a PL1 programmer in the early 90s. Methods that returned values were banned because:
a) Only returning a single value was "pretty useless".
b) Global variables were "more flexible".
c) None of the existing methods on the project return values.

Actually he wasn't a bad manager. In fact what he was doing was abitrating in an argument between another programmer (established on the project) and me (new to the project) and, unfortunately, I lost.

Vince.

We really do not want GUI builders...

You mightn't. I do. The whole purpose of an IDE is to automate the development and, these days, it is the GUI design that gives me the most headaches.

As a partial aside, IntelliJ is steadily becoming a tool laden with advanced functionality for advanced users. This is fine except that all users start out as beginners. We are getting plenty of ideas for advanced users but fewer that help beginners (or intermediates). If they get in the habit of using simpler IDEs then it won't do anything for IntelliJ sales in the future. Perhaps a lite version is required, I don't know.

In this respect, adding support for Java language extensions such as AspectJ particularly worry me.

Vince.

hi all.

here's my list in no particular order:

1. provide more controll over File Templates so that we can easily implement common file constructions with default behaviours and little dialogues like the Enumeration Class

2. view multiple files at once

3. provide more Class structure control like: organising methods; like an rtf javadoc editor; like hide/show by scope and others in Structure window

4. Put all source/classes in one tree in the Project window

5. Provide a more file management features in the Commander like: file/dir diffing, non-refactored control for deleteing/copying/renaming/etc., run scripts/executables/etc


Florian Hehlen

3. provide more Class structure control like: organising methods; like an rtf javadoc editor; like hide/show by scope and others in Structure window

+10! Issue 2719

4. Put all source/classes in one tree in the Project window

5 ( easier switch between the same package in different source
paths)

5. Provide a more file management features in the Commander like: file/dir diffing, non-refactored control for deleteing/copying/renaming/etc., run scripts/executables/etc

+1

Amnon I. Govrin wrote:

In IntelliJ 3 there are new features such as directory exclusion from
compilation. Also very easy with Ant.
I think that IntelliJ should use Ant at its galore, and create an Ant
script file for a project for all Ant features instead of reinventing the
wheel and creating an internal logistics for compilation, CVS integration,
and other features still missing such as packaging. This would not only
save development time for JetBrains, but would benefit developers by
providing a leaner and rounder IDE. For example, Compiling from IntelliJ
would simply call the relevant Ant target. Adding a source directory would
add it to the relevant path in the ant script. At the end of the day, all
of us doing daily/weekly builds through ant wouldn't have to replicate
actions in IntelliJ and an ant script.
We, for one, simply don't touch internal compilation in IntelliJ because
of that. Still, when we add a source directory, for example, we need to do
it in 2 places as IntelliJ won't know the sources if we don't add them to
the tree, and Ant won't compile them if we don't add the new directory in
the ant script.

For me using Ant is always a pain due to the long startup/execute times. On
the other hand a more advanced build process would be useful, too. A
compromise might be: keeping the current build setup but improving it for
more complicated tasks with Ant. I know that there is currently a plugin
available that creates Ant files from IDEA projects but it would be nice to
have a "[X] create jar file" button in the UI that would create an Ant task
for that.

Dirk Dittert

Thomas,

Looks like you've already spend your 5 votes (5 features) several days ago.
;)

--
Best regards,
Mike Aizatsky.
-

JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"

I don't see any performance problems using Ant. We've been using Ant only
and never touch internal compilation.

If Ant startup is a problem, one of the following could possibly be done:
1. Run Ant in a more eficient way, i.e. not launch a new JVM for it, but run
it internally.
2. If 1 is not currently possible, work with the Jakarta project developers
to enable it.

Amnon

"Dirk Dittert" <dittert@despammed.com> wrote in message
news:asib2i$hbf$1@is.intellij.net...

Amnon I. Govrin wrote:

>

In IntelliJ 3 there are new features such as directory exclusion from
compilation. Also very easy with Ant.
I think that IntelliJ should use Ant at its galore, and create an Ant
script file for a project for all Ant features instead of reinventing

the

wheel and creating an internal logistics for compilation, CVS

integration,

and other features still missing such as packaging. This would not only
save development time for JetBrains, but would benefit developers by
providing a leaner and rounder IDE. For example, Compiling from IntelliJ
would simply call the relevant Ant target. Adding a source directory

would

add it to the relevant path in the ant script. At the end of the day,

all

of us doing daily/weekly builds through ant wouldn't have to replicate
actions in IntelliJ and an ant script.
We, for one, simply don't touch internal compilation in IntelliJ because
of that. Still, when we add a source directory, for example, we need to

do

it in 2 places as IntelliJ won't know the sources if we don't add them

to

the tree, and Ant won't compile them if we don't add the new directory

in

the ant script.

>

For me using Ant is always a pain due to the long startup/execute times.

On

the other hand a more advanced build process would be useful, too. A
compromise might be: keeping the current build setup but improving it for
more complicated tasks with Ant. I know that there is currently a plugin
available that creates Ant files from IDEA projects but it would be nice

to

have a "[X] create jar file" button in the UI that would create an Ant

task

for that.

>

Dirk Dittert

This is fine except that all users start out as beginners. We are getting
plenty of ideas for advanced users but fewer that help beginners (or intermediates).

I envision the beginners functionality as separate plugins which you can download and
install. For example there could be Basic Java Tutor plugin where a little paperclip will
tell you "Hey, it looks like you are writing a thread, why not make it Runnable." or vice
versa :)

This looks like logical extrapolation of the idea for intentions and inspections. I.e. a
tutor plugin could be a set of intentions + a set of inspections + some help files and
some UI.

All these plugins should ASSIST YOU TO LEARN how to do the things right instead of help us
producing piles of lame code.

-- dimiter

To disqualify a GUI Builder (that is where this sub-thread is based on) as a "beginners" tool is imho wrong, because it depends on how it is implemented. If IntelliJ comes up with a good approach that fits to the product's philosophy, it could serve developers involved in client GUI programming.

I guess, that the majority of IntelliJ users is involved in server side programming, so that a GUI Builder may not matter for them.

However, I have read books, heard recommendations where it is said that server side programming should best be done with IntelliJ, whereas client programming is more productive with JBuilder (because of its GUI Builder).

Thus, it seems that depending on the programming task developers / teams may choose one or the other product.

The conclusion could be that with providing an intelligent GUI Builder, IntelliJ can get more market share, which gives JetBrains more strength to survive the current IDE market, which seems to be characterized by mergers and product deaths presently (see VisualCafe, and the Borland / Together merger).

Thomas G?lden
Munich, Germany

Fully agree, my post was not about a GUI builder (which I might even like if implemented
properly).

My post was about "Add this and thiss feature to the IDE because I don't know how to do it
myself"

There is an old Bulgarian tale about a beggar and a fisherman:
The beggar asked the fisherman for a single fish to feed his children, but the fisherman
told him: "I won't give you a fish. Instead if you like, come with me, I'll learn you to
catch it yourself"

It might be even more effort to create such "crutch plugins" but I believe that this would
be the right thing.

regards,
dimiter

.... there are a lot of interesting RFEs reported by others. Just
wanted to add my "Hey, this is a good idea, I could make use of, too."
;)

Cheers,
Tom

Amnon I. Govrin wrote:

If Ant startup is a problem, one of the following could possibly be done:
1. Run Ant in a more eficient way, i.e. not launch a new JVM for it, but
run it internally.

you mean: leave in the properties the execute in custom VM unchecked? I
already did that. The first compile takes about 25sec (just a bunch of
classes) compared to about 8 sec with internal compilation. Syntax checking
in the editor helps but sometimes I still need to compile and then Ant is a
pain for bigger projects.

2. If 1 is not currently possible, work with the Jakarta project
developers to enable it.

I'd prefer:

3. work with the HP engineers to make it possible to put more memory into my
laptop. I have reached the maximum amount of 256MByte...

Any more tips for speedups?

Best regards,

Dirk Dittert

"Dirk Dittert" <dittert@despammed.com> wrote in message
news:asirau$irs$1@is.intellij.net...

I'd prefer:

>

3. work with the HP engineers to make it possible to put more memory into

my

laptop. I have reached the maximum amount of 256MByte...

I had this problem with my HP laptop too. My solution was to spend $500 and
buy a fast desktop computer. I am developing with a lot more pleasure now
that I have a 1.8 GHz machine with 1 GB of RAM :)


Erik

1. Hot Swap (Most important feature for me!!!)
2. Finish ANT integration. CTRL-B on variables should also work if you use (and I think many use) properties files for some build variables. Also CTRL-B does most of the time not work on targets!!! (Btw there should also be a CTRL-Click for that)
3. Better CVS integration. At the moment out-of-date files are not recognized (wouldn't be so bad if there was a refresh button...). Tag command is missing.
4. GUI-builder would be nice although I think NetBeans does a good job for this. Perhaps IDEA could be the first(heard about Borland supporting Droplets) to come up with a web-gui builder. Think about supporting Java ServerFaces.
5. For every feature please try to not decrease speed!!!

you mean: leave in the properties the execute in
custom VM unchecked? I
already did that. The first compile takes about 25sec
(just a bunch of
classes) compared to about 8 sec with internal
compilation.

Do you clean all files before compilation ?
If so, the ]]> task might help. It helped me alot.

Erik Hanson wrote:

I had this problem with my HP laptop too. My solution was to spend $500
and buy a fast desktop computer. I am developing with a lot more pleasure
now that I have a 1.8 GHz machine with 1 GB of RAM :)

I will move back to Germany in a few months. Therefore I do not really want
to spend a lot of money for things I can't take with me...

Best regards,

Dirk Dittert

1. JSP/HTML/JavaScript formatting
2. JRun4 integration. Specifically, JSP debugging with JRun4.

"Alain Ravet" <alain.ravet.list@wanadoo.be> wrote in message
news:as5dj8$g84$1@is.intellij.net...

What would change your java programmer's life, and how can IDEA make it
happen?

>

With 1110 features requests currently open/submitted in the tracker, the
voting system won't do any good at hinting IDEA people about what we
wish/need.

>
>
>

What does your wish list look like. No, what are the 5 first items on
your wish list?

>

Don't think too much, don't search : what do you miss today?
(Keep the lists short : no need the replicate the features tracker!)

>

Alain Ravet

>

Totally, I mean 100% agree with you.
At my current project performance is a "must" so for me feature number one
would be a profiling tool combining it with deeper inspection capabilities
will definitely justify for us upgrade to 4.0.

AlexO

"Jonathan Knight" <jiveadmin@jetbrains.com> wrote in message
news:4517319.1038828709385.JavaMail.jrun@is.intellij.net...

We really do not want GUI builders or UML. Don't turn IDEA into a Rational

or Together. You will not be able to make IDEA a good UML tool without
loosing a lot of the things it is good at now. All these UML tools force you
to work in a particular way, which IDEA does not.

If people want these then make them plugins so someone else can develop

them. So maybe making the Open API better should be a goal along with the
PSI api then people can easily develop good plugins.
>

IDEA should stick to what its good at, a damn good IDE. I have yet to find

a good GUI builder. I am currently working on a pure Swing project and IDEA
is fine, I wouldn't use anything else. Coding GUIs by hand is not a problem.
Some of the screens in the project could not be build in a GUI builder
anyway as the makeup of the screen changes at run time.
>

Things like the refactoing and code inspection save me far more time than

things like a gui builder would. Put in more of these like the duplicate
code inspections mentioned earlier.
>

4.0 wish list:

+ improved performance, more fixed bugs, and not for features I won't ever use. I want 4.0 to be as slick as 2.6 was.

+ aspectj

+ published, full featured, supported, OpenAPI

+1
"dimiter" <dimiter@blue-edge.bg> wrote in message
news:asff4h$mb1$1@is.intellij.net...

so to say it sortly the patten support is more a feature of the programmer

and not of the

IDE he's using...

>

ok i do

+2

"Thomas G?lden" <jiveadmin@jetbrains.com> wrote in message
news:5912536.1038928852473.JavaMail.jrun@is.intellij.net...
To disqualify a GUI Builder (that is where this sub-thread is based on) as a
"beginners" tool is imho wrong, because it depends on how it is implemented.
If IntelliJ comes up with a good approach that fits to the product's
philosophy, it could serve developers involved in client GUI programming.

I guess, that the majority of IntelliJ users is involved in server side
programming, so that a GUI Builder may not matter for them.

However, I have read books, heard recommendations where it is said that
server side programming should best be done with IntelliJ, whereas client
programming is more productive with JBuilder (because of its GUI Builder).

Thus, it seems that depending on the programming task developers / teams may
choose one or the other product.

The conclusion could be that with providing an intelligent GUI Builder,
IntelliJ can get more market share, which gives JetBrains more strength to
survive the current IDE market, which seems to be characterized by mergers
and product deaths presently (see VisualCafe, and the Borland / Together
merger).

Thomas G?lden
Munich, Germany

"Thomas Singer" <idea@regnis.de> wrote:

The existing GUI-builders are only usable for prototyping. I don't
know of any, that could be used successfully for any production
system.

Imagine a GUI builder that supported refactoring...

"Encapsulate controls in custom component"
"Promote ActionListener to Action"
"Convert Layout to GridBagLayout"

...and all the others I haven't thought of yet. You could also have
insert-menu options for event handlers, listener management methods and so
on. Then there could be intentions for binding a property to a GUI control
(so that changing the property would cause the control to be updated), and
no doubt many others too. Now *that* is the sort of GUI builder that I would
want to use.

Vil.
--
Vilya Harvey, Consultant
vilya.harvey@digitalsteps.com / digital steps /
(W) +44 (0)1483 469 480
(M) +44 (0)7816 678 457 http://www.digitalsteps.com/

Disclaimer

This e-mail and any attachments may be confidential and/or legally
privileged. If you have received this email and you are not a named
addressee, please inform the sender at Digital Steps Ltd by phone on
+44 (0)1483 469 480 or by reply email and then delete the email from
your system. If you are not a named addressee you must not use,
disclose, distribute, copy, print or rely on this email. Although
Digital Steps Ltd routinely screens for viruses, addressees should
check this email and any attachments for viruses. Digital Steps Ltd
makes no representation or warranty as to the absence of viruses in this
email or any attachments.

Imagine a GUI builder that supported refactoring...

>

"Encapsulate controls in custom component"
"Promote ActionListener to Action"
"Convert Layout to GridBagLayout"

>

...and all the others I haven't thought of yet. You could also have
insert-menu options for event handlers, listener management methods and so
on. Then there could be intentions for binding a property to a GUI control
(so that changing the property would cause the control to be updated), and
no doubt many others too. Now that is the sort of GUI builder that I

would

want to use.

I haven't participated yet in the debate regarding the Shakespearean issue
of "To have a Gui builder or not to have a Gui builder, that is a question",
but your post is certainly the most innovative one in this whole thread.
You have just given really wonderful ideas of what a really innovative Gui
builder could be.
Thank you! Maybe we should continue brainstorming on that subject.
Two main idea come to my mind, inspired from IntelliJ's philosophy :
- intentions
- refactorings.
We should focus on those two things : what are the intentions and
refactorings we could need to build/desing/modify a Gui builder ?

For the moment, I don't really need a Gui builder, because I'm essentially
working on JSP/Servlet stuffs, but I might soon work on a kind of RAD tool
over a custom application framework for my company. And I'd especially be
interested in a Gui builder in a near future. Regarding this Gui stuff, I
was wondering how a Gui builder could be used to create dynamic
windows/panels/dialogs, etc. Because for this project, I might need to
create dynamic dialogs, and usually, Gui builders are just capable of
handling/designing static stuffs. I can't come across a good idea for
creating dynamic stuffs. The idea of properties bound to Gui controls might
be a solution.

Guillaume

1) visibility sorting in structure view
http://www.intellij.net/tracker/idea/viewSCR?publicId=2513

2) package view of the sources.
http://www.intellij.net/tracker/idea/viewSCR?publicId=3132

3) ability to define multiple classpath, besides the default one, in a
project and associate one of them per run configuration.
http://www.intellij.net/tracker/idea/viewSCR?publicId=7846

4) multiple debuggers per project - useful only if we have 3)
http://www.intellij.net/tracker/idea/viewSCR?publicId=7266
http://www.intellij.net/tracker/idea/viewSCR?publicId=5088
http://www.intellij.net/tracker/idea/viewSCR?publicId=3766
(intellij, you need to close some as duplicates)

5) ]]>


Edo

Alain Ravet wrote:

What would change your java programmer's life, and how can IDEA make it
happen?

With 1110 features requests currently open/submitted in the tracker, the
voting system won't do any good at hinting IDEA people about what we
wish/need.



What does your wish list look like. No, what are the 5 first items on
your wish list?

Don't think too much, don't search : what do you miss today?
(Keep the lists short : no need the replicate the features tracker!)

Alain Ravet

My five favourites, all concerning the web support:

- inclusion of generated JSP servlets ("Show Servlet" and side-by-side debugging)
http://www.intellij.net/tracker/idea/viewSCR?publicId=4194

- "Find Usages" for web resources (like JSP and HTML files)
http://www.intellij.net/tracker/idea/viewSCR?publicId=4536

- of course: JSP code formatting

- a small one: "Go to Declaration" for jsp:forward "page" attribute
http://www.intellij.net/tracker/idea/viewSCR?publicId=7854

- Tomcat 4.1 integration (Run/Debug WebApp, without JSP breakpoints if that is not possible)

I would be very happy to see the latter two already in IDEA 3.1 or even 3.0.2, as I do not consider them much effort.

Juergen

"Vilya Harvey" <vilya.harvey@digitalsteps.com> wrote:

Imagine a GUI builder that supported refactoring...

"Encapsulate controls in custom component"
"Promote ActionListener to Action"

This is one key-problem of the known tools. Good UI design makes
extensive use of Actions (or more powerful subclasses), but in my
knowledge of GUI builders, only Delphi-like ActionListeners are
supported.

"Convert Layout to GridBagLayout"

Imagine a GUI builder that supports:
- custom components (e.g. subclasses of JPanel, JTable, JTree; maybe
with no default constructor)
- component factories (e.g. JButton createButton(MyAction); JMenuItem
createMenuItemWithIcon(MyAction); JMenuItem
createMenuItemWithoutIcon(MyAction);)
- global distance settings (between components)
- powerful layout (e.g. OK and Cancel buttons have the same size and
are always right aligned in a ButtonPanel)
...

As more I think over the GUI builder's requirements the more I
believe, it will be impossible, because the most flexibility is only
available with a good GUI framework, that makes more high-level use of
the Swing components.

Example: If I want to change the distance between components (in all
dialogs of an application!) from 2 to 4 pixels, I need to change one
line in our GUI framework. Try to do this with a GUI builder: you need
to take each dialog and change the settings of hundreds of components.

What about obfuscation (a "must-have" for desktop applications), when
-- as some people suggested -- the whole GUI design is made with the
help of XML-files?

Just some thoughts from a Swing experienced developer ...

Cheers,
Tom