What's NetBeans written in?

[VijayS]

I always thought NetBeans was a C++ app, but is it really Java?

Why is NetBeans so much faster than Eclipse (in terms of UI
responsiveness, compilation, etc)?

We're having a heated internal debate about which IDE to use in-house.
Up till now, we've used textpad+ant.

Extensibility is one of our key reqs, but both IDEs fit the bill
there.

I appreciate any help,

Thanks,
-Vijay

 

[Philipp Leitner]

Why is NetBeans so much faster than Eclipse (in terms of UI

responsiveness, compilation, etc)?

Is it? I always shyed away from Netbeans because I had the impression
that it was so terribly slow (on my slightly outdated iBook G4) ...
granted, Eclipse also doesn't win a price on general responsiveness,
but it at least feels a lot quicker than Netbeans on my machine.

 

[Lew]

I always thought NetBeans was a C++ app, but is it really Java?

Why is NetBeans so much faster than Eclipse (in terms of UI
responsiveness, compilation, etc)?

We're having a heated internal debate about which IDE to use in-house.
Up till now, we've used textpad+ant.

Extensibility is one of our key reqs, but both IDEs fit the bill
there.

Why not let each developer pick their own IDE? Why the dictatorial approach?

Project builds should be done via Ant anyway, not through an IDE. All IDEs
emit text in the end; if a developer prefers vi and they meet their deadlines
and quality goals, more power to them.

Don't shackle your developers.

 

[Lew]

Is it? I always shyed away from Netbeans because I had the impression
that it was so terribly slow (on my slightly outdated iBook G4) ...
granted, Eclipse also doesn't win a price on general responsiveness,
but it at least feels a lot quicker than Netbeans on my machine.

Maybe NetBeans is just plain better written. I've always preferred it to Eclipse.

There are more metrics than UI speed. The consistency and ease of use of the
UI are arguably much more important. To my mind, NetBeans is much easier to
use and has a richer feature set. It's much easier to deploy apps via
NetBeans, for me, and to deploy and connect to app servers, databases and the
like. By comparison I find the Eclipse UI much more recalcitrant and hard to
navigate. Both IDEs tend to hide important aspects of the build, such as
library inclusion, from the developer, but both export the needed libraries to
the deployment artifacts. NetBeans also has that nice Matisse plugin for
developing Swing apps.

NetBeans also has better features for folding in the Struts or JSF frameworks
and for SOAP Web services development.

But lest we fall into the trap of fighting
<http://en.wikipedia.org/wiki/Editor_wars>
developers should be free to pick their own editors. They all emit text, and
all feed the same project build process, so at the project-management level
the differences vanish.

 

[Tom Hawtin]

Is it? I always shyed away from Netbeans because I had the impression
that it was so terribly slow (on my slightly outdated iBook G4) ...
granted, Eclipse also doesn't win a price on general responsiveness,
but it at least feels a lot quicker than Netbeans on my machine.

NetBeans is written in Java. I find it horrendously slow (5.5 and 6.0M10).

The original poster appears to be using an Intel Mac. AIUI, SWT has
always sucked on Macs. I don't know if it is any better or worse on
Intel vs PPC Macs. On Linux you might find Eclipse installed on an old
barely functioning GNU "Java", which you'd expect to be slow.

IIRC, the Eclipse compiler is often said to be faster than javac. AIUI,
Eclipse will compile in the background, so you don't have to wait for
ANT to chug away as you do on Eclipse.

YMMV

Tom Hawtin

 

[David Segall]

Why not let each developer pick their own IDE?
Why the dictatorial approach?

Because Java is a third generation language and a fairly primitive one
at that. By dictating the IDE a company can obtain some of the
advantages of a higher level language while retaining the underlying
portability of Java.

Project builds should be done via Ant anyway, not through an IDE. All IDEs
emit text in the end; if a developer prefers vi and they meet their deadlines
and quality goals, more power to them.

If another programmer changes my Matisse GUI using vi the text he
emits will not include the text required for me to continue using
Matisse.

 

[Mike Schilling]

I always thought NetBeans was a C++ app, but is it really Java?

Definitely Java. It's open source; if you like, go to their website and
download the source.

 

[Roedy Green]

Why not let each developer pick their own IDE? Why the dictatorial approach?

You do need a common code beautifier so that you don't get false
deltas on cvs checkin. Eclipse and IntelliJ can be made to look
roughly the same, but not identical. What is needed is a beautifier
plugin that works on all the major IDES and hooks itself up to
automatically beautify before checkin.

 

[Matthias Buelow]

You do need a common code beautifier so that you don't get false
deltas on cvs checkin. Eclipse and IntelliJ can be made to look
roughly the same, but not identical. What is needed is a beautifier
plugin that works on all the major IDES and hooks itself up to
automatically beautify before checkin.

What kind of nonsense is that? It's not as if the editor would reindent
all the code upon loading a file -- if it does, throw it away faster
than it starts up.

 

[Guest]

Why not let each developer pick their own IDE? Why the dictatorial
approach?

Project builds should be done via Ant anyway, not through an IDE. All
IDEs emit text in the end; if a developer prefers vi and they meet their
deadlines and quality goals, more power to them.

Don't shackle your developers.

I agree.

But a lot of team leads would sing the song about training,
help, project files etc.etc..

Arne

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Because Java is a third generation language and a fairly primitive one
at that. By dictating the IDE a company can obtain some of the
advantages of a higher level language while retaining the underlying
portability of Java.

By convention third generation languages are called
high level languages.

If another programmer changes my Matisse GUI using vi the text he
emits will not include the text required for me to continue using
Matisse.

Is that vi's or Matisse's fault ?

Arne

 

[Lew]

This is an argument against using a single IDE, not in favor of it. The
trouble with standardizing on an IDE instead of just a platform and a language
is that you get IDE depencies in your product, a Bad Thing.

Is that vi's or Matisse's fault ?

Good question.

It should be a matter of policy that no one can check code into the repository
that breaks the build (compile step). It should be a matter of policy that no
IDE dependencies exist in the code repository. The right way to build a Java
program is from source, a pure text medium, using Ant. vi is certainly
capable of emitting all the text needed for a successful build, in the hands
of a competent developer. Ditto emacs, JBuilder, JEdit, NetBeans, Eclipse,
OAD, WSAD, yada effing yada.

Management needs to get it, and get off the developers' backs about such
stupidity as mandating an IDE.

 

[Lew]

I agree.

But a lot of team leads would sing the song about training,
help, project files etc.etc..

Then the organization should fire that team lead and hire someone who knows
what they're doing.

 

[David Segall]

This is an argument against using a single IDE, not in favor of it. The
trouble with standardizing on an IDE instead of just a platform and a language
is that you get IDE depencies in your product, a Bad Thing.

Not really. If your IDE vanishes then, with a little effort, you can
transfer your source code to punched cards and run it on any platform
that supports Java and has appropriate hardware. Meanwhile you can
enjoy the huge gains that a modern IDE provides. It only requires that
the project team agree on some standard software. That software will
range from source code control to 4GL development tools and an IDE is
a convenient way of integrating them.

 

[Lew]

Not really. If your IDE vanishes then, with a little effort, you can

It's that "little effort" that I seek to avoid by not forcing the build to
depend on any given IDE.

transfer your source code to punched cards and run it on any platform
that supports Java and has appropriate hardware. Meanwhile you can
enjoy the huge gains that a modern IDE provides.

Of course you can, and should, just not by dictating to the professional what
tools will give them the most of those gains.

It only requires that the project team agree on some standard software. That software will

Au contraire, it not only does not require that, but requiring one specific
IDE could tend to mitigate the gains you get from IDEs. More effective is to
require a certain performance goal, and leave it to the highly-trained
professionals how best to achieve that goal.

Mandating a particular IDE for software developers is like mandating a
particular brand of hammer or other tool for your carpenters - you could do
it, but there really is not a benefit and potentially some detriment.

The best compromise is to insist that anyone /can/ build the project
effectively using the standard IDE. So while I might hare off and use
NetBeans to build my J2EE assignment (and will do so, given the choice), any
team member can open it in the team's standard IDE, say Eclipse, and
successfully build and test my code. The organization can also cluck and tell
me that I'm on my own with NetBeans but they'll willingly support Eclipse.
And fire me if I slip my deadlines. Thus, freedom with an inducement to stay
with the team choice.

range from source code control to 4GL development tools and an IDE is
a convenient way of integrating them.

I am with you on the benefits of IDEs. Use'em myself, ayep.

 

[Guest]

It should be a matter of policy that no one can check code into the
repository that breaks the build (compile step).

That is not what he is talking about.

He is talking about the fact that manually editing code generated
by a GUI builder will prevent other users from using the GUI builder
in the future, because the GUI builder relies on certain comments
and idioms.

Arne

 

[Guest]

Then the organization should fire that team lead and hire someone who
knows what they're doing.

I would think it is in the 80%-95% of places where such rules
exist ...

Arne

 

[Lew]

He is talking about the fact that manually editing code generated
by a GUI builder will prevent other users from using the GUI builder
in the future, because the GUI builder relies on certain comments
and idioms.

I would call that an IDE dependency and consider the use of that GUI builder a
risk.

 

[Roedy Green]

What kind of nonsense is that? It's not as if the editor would reindent
all the code upon loading a file -- if it does, throw it away faster
than it starts up.

Let's say programmer A checks out the code and does some extensive
work with in IntelliJ. Almost certainly he will hit Ctrl-Alt-R
several times to make the code comprehensible. It will beautify to
IntelliJ specs.

Then he checks it in. Programmer B checks it out in Eclipse and does
a simple modification. Hits the beautify button, which will beautify
to Eclipse standards -- potentially changing every line in the
program, changed or not. He then checks it in.

Then programmer A checks it out again. And tries to figure out what
Programmer B changed. CVS tells him every line in the program had a
delta.

If they both used a COMMON beautifier before checkin, CVS would report
only REAL changes to code, not ones artifacts of differing styles of
beautification.

 

[Roedy Green]

Then the organization should fire that team lead and hire someone who knows
what they're doing.

The smartest boss I ever had was also so meticulous he drove team
members mad. Further he could not appreciate that everyone was not as
brilliant as he was. He expected everyone to follow extremely
intricate code as effortlessly as he did.

Several times in my life I have had the exquisite pleasure to lead a
team of highly competent people who did not fight with me, but who
were not shy about pointing out my errors. It is the most incredible
feeling to see finished code pouring out at a clip an order of
magnitude faster than I could possibly do it myself, all done the way
I would have had I the time and patience.

Being the boss is such a pleasure, I can see why incompetent people
love to try anyway.