IDEA 7 vs. NetBeans 6

Netbeans 6 had a massive leap in terms of quality, but it is still way behing IDEA.
The truth is that while other IDEs get more sophisticated (funnily, almost always "copying" IDEA's features) so does IntelliJ IDEA.
I can't imagine any of the other big ones (Netbeans, Eclipse...) overtaking IDEA in the near future.

IMHO, quite disappoiting was Sun's idea of pushing Ruby as a second language for their software and leave Groovy on the dry.

IDEA's support for Groovy is not perfect, but is by far the best available anywhere.

Hi,

the only NetBeans 6 feature that I think really beats IDEA is NB's Maven2 integration. Of course, IDEA 7 also can open a pom.xml as a project, but then it builds an IDEA project from it. For NB, the pom.xml IS the project. Also when compiling in NB, Maven2 is used, that is the modified files' poms are built, while IDEA uses its own compiler.

Another nice thing in Maven2 integration I found in NB: you execute the unit tests of a pom (mvn test), and if the tests fail, you can click-through into the test results of the failing test. When starting the maven tests from IDEA, you only see the console output, but for looking into the test results file, you have to open it manually.

I would appreciate very much such a tight Maven2 integration in IDEA, since this is IMO the only thing where IDEA is not on top.

Hello Martin,

the only NetBeans 6 feature that I think really beats IDEA is NB's
Maven2 integration. Of course, IDEA 7 also can open a pom.xml as a
project, but then it builds an IDEA project from it. For NB, the
pom.xml IS the project. Also when compiling in NB, Maven2 is used,
that is the modified files' poms are built, while IDEA uses its own
compiler.

We consider this to be a strong advantage of IntelliJ IDEA, because it, unlike
Maven, has a very smart incremental compiler which recompiles only the classes
directly affected by the latest changes in the code.

Another nice thing in Maven2 integration I found in NB: you execute
the unit tests of a pom (mvn test), and if the tests fail, you can
click-through into the test results of the failing test. When starting
the maven tests from IDEA, you only see the console output, but for
looking into the test results file, you have to open it manually.

This is something we would like to support, most likely in version 8.

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

One place where NetBeans 6 really shines is its visual jsp/jsf editor. I'm not a strong jsp programmer, so I appreciate being able to design a jsp page with the visual editor, then study the generated jsp code.

I've never found a visual jsp editor plugin for IDEA. If one exists and I've just overlooked it, I would appreciate hearing about it.

Other than the visual jsp editor, I find NetBeans 6 too buggy and slow.

IDEA 7 has been rock-solid for me. The feature set is great and performance is unmatched.

Thanks IntelliJ.

I think you'll find that the majority of people who write JSPs for a living don't like "visual" editors because they produce poor quality code that's very hard to maintain and modify.
Of course those who create such editors don't really care about that because in their world view people never need to do anything that the editor doesn't support and noone on any team will work without it.
In the real world though teams used mixed tools, and often run into the limitations of code generating editors so don't want to be forced into using them for everything.

I personally would be happy with a JSP/JSF VIEWER that allows me to click an element (text input, textarea etc.) in the GUI and when returning to the source code have the relevant tag(s) in the JSP file selected. That would really help when dealing with long complicated JSPs.
And you will see those when maintaining legacy applications.

That's right imho. The IDEA is my IDE of choice because it's best for writing the code. But I can see a weakness in JavaEE support, especially compared to Eclipse. I envy my Eclipse colleagues the visual XSD editor. And the Eclipse like visual jBPM editor plugin for business process modelling used in Seam would be also great.

I think you'll find that the majority of people who write JSPs for a living don't
like "visual" editors because they produce poor quality code
that's very hard to maintain and modify.

IMHO that's just a cheap argument.
The same one that was brought here before Jetbrains started their GUI builder:
You can search these archives and see that exactly (you need to dig a few years back, but the're
still here).

Given the Jetbrains GUI builder is not the best(for everybody), take a look at JFormDesigner (
and try it a few minutes to see what I mean) to see that the argument from a few years ago is not
valid, the same way your argument now for JSP is not (IMHO).


Ahmed.

Ahmed Mohombe wrote:
>> I think you'll find that the majority of people who write JSPs for a
>> living don't like "visual" editors because they produce poor quality
>> code that's very hard to maintain and modify.

IMHO that's just a cheap argument.
The same one that was brought here before Jetbrains started their GUI
builder:
You can search these archives and see that exactly (you need to dig a
few years back, but the're
still here).

Given the Jetbrains GUI builder is not the best(for everybody), take a
look at JFormDesigner (
and try it a few minutes to see what I mean) to see that the argument
from a few years ago is not valid, the same way your argument now for
JSP is not (IMHO).


Ahmed.

Do you write GUI code every day for a living then Ahmed?

N.

Do you write GUI code every day for a living then Ahmed?

Yes, I do.
Last projects include mostly fat swing clients too for JEE apps.

Ahmed.

There may be exceptions, but overall my argument is still quite valid.
Code generators in general create code that's hard to maintain outside the scope of that code generator (and some reject any attempt to do so, like for example Netbeans).
They also dictate sub-optimal application models, usually riddled with dependencies between display code and its backing business logic, simply because they have no (easy) way to allow for calling external logic, instead requiring everyting to be in one place, where they can control it.