Eclipse And NetBeans

[Steve]

I've been using Visual Slickedit for over 10 years. I'm now working my
way through the help files in Eclipse. I decided to give it a try
since it is *almost* a defacto standard in Java shops.

I've been impressed with what I have seen so far.

I understand that the other contender for popular, free, plugin based
JAVA IDE is NetBeans.

I understand there may just be religious issues as far as which one a
person should choose, but while I understand the differences in
philosophies between an older religious war: emacs and vi, I don't with
Eclipse and NetBeans.

Both are written in Java, both are IDEs, both are built to take in new
functionality via plugins.

So, what are the big differences between the two that make some people
go with one and others with the other?

Thanks in advance for any polite, non-critical, non-negative opinions

Steve

[William Colls]

From limited experiance with both, I found Netbeans easier to get
productive with. It is simpler, and for me intuitive to use. I found
Eclipse less intuitive, and in some cases the help wasn't much help. I
suspect that Netbeans is fine for relatively small projects, with only a
few team memebers. Eclipse seems to be aimed at larger projects, with a
large team.

William.

[Arved Sandstrom]

I know you mentioned free, but the general arguments apply also for
IntelliJ IDEA.

At any given time, for a particular job, the support may be markedly
better in one IDE than in the others. In fact it may be missing in one
while another has it. Bear in mind, these are IDEs, not just Java
editors and Java build toolsets. People use a variety of build and
source control systems in these things, a whole bunch of different
programming languages...you know what I'm talking about, you've looked
at what these IDEs do.

So for a particular job it's fairly common that one IDE or the other
stands out. For the most common tasks there aren't large differences at
all, any IDE will serve. I tend to keep all of them available for niche
jobs.

What I usually do for specialized work is Google on the IDE comparison
for that specialized work. It's what actually matters, after all. For
example, I may prefer NB generally for Java work (I'm just sayin') but
if Eclipse has by far the better plugin for a particular version of a
particular app server, that might swing the choice for that project.

For newer APIs or technologies it's not uncommon to see that Eclipse
gets plugins first, then NB and IDEA catch up.

In the workplace I often go with Eclipse simply because that's what the
client/customer team uses, and uniformity is important.

AHS
--
A fly was very close to being called a "land," cause that's what they do
half the time.
-- Mitch Hedberg

[Lew]

William Colls wrote:
> Steve wrote:
>> I've been using Visual Slickedit for over 10 years. I'm now working my
>> way through the help files in Eclipse. I decided to give it a try since
>> it is *almost* a defacto standard in Java shops.
>>
>> I've been impressed with what I have seen so far.
>>
>> I understand that the other contender for popular, free, plugin based
>> JAVA IDE is NetBeans.
>>
>> I understand there may just be religious issues as far as which one a
>> person should choose, but while I understand the differences in
>> philosophies between an older religious war: emacs and vi, I don't with
>> Eclipse and NetBeans.
>>
>> Both are written in Java, both are IDEs, both are built to take in new
>> functionality via plugins.
>>
>> So, what are the big differences between the two that make some people
>> go with one and others with the other?

What are the differences between emacs and vi? Both are written in older computer languages, both are built to edit text files, both have advanced features to help programmers.

What's the difference between a Piper Cub and a Boeing 747? Both are fixed-wing aircraft. Both carry passengers through the air. Both require a licensed pilot and an airfield.

Style, key mappings, number of menu features, robustness of help system, low-level implementation details like how Eclipse shadows the file system but not NetBeans, support for outboard features (like other languages besides Java), how they're packaged for installation, ...

>> Thanks in advance for any polite, non-critical, non-negative opinions

Nice try, but we will still say what we will.

> From limited experiance with both, I found Netbeans easier to get
> productive with. It is simpler, and for me intuitive to use. I found
> Eclipse less intuitive, and in some cases the help wasn't much help. I
> suspect that Netbeans is fine for relatively small projects, with only a
> few team memebers. Eclipse seems to be aimed at larger projects, with a
> large team.

I like NetBeans but currently I am tied to Eclipse.

--
Lew

[Robert Tomsick]

On Thu, 19 Apr 2012, Arved Sandstrom wrote:

> On 12-04-19 05:35 PM, Steve wrote:
>> I've been using Visual Slickedit for over 10 years. I'm now working my
>> way through the help files in Eclipse. I decided to give it a try
>> since it is *almost* a defacto standard in Java shops.
>>
>> I've been impressed with what I have seen so far.
>>
>> I understand that the other contender for popular, free, plugin based
>> JAVA IDE is NetBeans.
>>
>> I understand there may just be religious issues as far as which one a
>> person should choose, but while I understand the differences in
>> philosophies between an older religious war: emacs and vi, I don't with
>> Eclipse and NetBeans.
>>
>> Both are written in Java, both are IDEs, both are built to take in new
>> functionality via plugins.
>>
>> So, what are the big differences between the two that make some people
>> go with one and others with the other?
>>
>> Thanks in advance for any polite, non-critical, non-negative opinions
>>
>> Steve
>

[...]

> At any given time, for a particular job, the support may be markedly
> better in one IDE than in the others. In fact it may be missing in one
> while another has it. Bear in mind, these are IDEs, not just Java
> editors and Java build toolsets. People use a variety of build and
> source control systems in these things, a whole bunch of different
> programming languages...you know what I'm talking about, you've looked
> at what these IDEs do.
>
> So for a particular job it's fairly common that one IDE or the other
> stands out. For the most common tasks there aren't large differences at
> all, any IDE will serve. I tend to keep all of them available for niche
> jobs.

[...]

> In the workplace I often go with Eclipse simply because that's what the
> client/customer team uses, and uniformity is important.

Excellent points. For me the answer of whether to use Netbeans, Eclipse,
or some other environment pretty much comes down to the answer to the
question "What is the rest of the team using?"

I've worked on projects where different members of the team used different
IDEs. Those projects did not exist in that state for long.

For personal projects (where I'm the only developer) I tend to go with
NetBeans if only because it handles PHP vastly better than PDT (or at
least it did when last I checked.) Obviously if you just do Java that
doesn't matter, but as someone whose non-day-job work involves both
languages, the ability to use the same IDE for both my Java and my PHP
work is a major plus.

-Rob

[Lew]

Robert Tomsick wrote:
> I've worked on projects where different members of the team used different
> IDEs. Those projects did not exist in that state for long.

Why in the world would it matter that different people use different editors
or IDEs? That makes no sense.

I have worked on teams for years where people used different IDEs and editors.
It didn't cause problems unless either management objected (never for any
solid engineering reason) or people checked IDE artifacts into source control.

There's absolutely nothing wrong with each team member using a different
editor or IDE, and much right.

--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[Arved Sandstrom]

On 12-04-26 11:30 AM, Lew wrote:
> Robert Tomsick wrote:
>> I've worked on projects where different members of the team used
>> different
>> IDEs. Those projects did not exist in that state for long.
>
> Why in the world would it matter that different people use different
> editors or IDEs? That makes no sense.
>
> I have worked on teams for years where people used different IDEs and
> editors. It didn't cause problems unless either management objected
> (never for any solid engineering reason) or people checked IDE artifacts
> into source control.
>
> There's absolutely nothing wrong with each team member using a different
> editor or IDE, and much right.
>

Often enough - we are not necessarily discussing vanilla Java
development here - one IDE will do certain tasks better (maybe much
better) than other IDEs. These certain tasks are required by the job at
hand. Rather than allow some aficionado of IDE X to flail away trying to
make something work, when it would definitely work easily in IDE Y, you
simply step in as the team lead and mandate IDE Y.

As for IDE artifacts in source control, there is nothing wrong, IMO,
with checking in non-workstation-specific project configurations. I've
seen this practise, for example, substantially reduce the time needed to
get new devs up to speed. This can also be used to communicate other
standardizations, rather than having people read a wiki someplace and
manually set up team-mandated settings in their IDEs.

This is obviously a hotly debated topic. There are quite a few Stack
Overflow threads dealing with it, and a mix of opinions. Some
vociferously argue for only source and libraries, others argue like me.
Some who are in the "no config files" camp also argue for using Maven to
generate these files: this is where my prejudices show, because I
dislike Maven and wouldn't urge its use on anyone.

You're right, sort of - there isn't anything inherently wrong, as a
rule, with team members using different IDEs...except when circumstances
don't promote that freedom of choice.

[Lew]

Arved Sandstrom wrote:
> Lew wrote:
>> Robert Tomsick wrote:
>>> I've worked on projects where different members of the team used
>>> different
>>> IDEs. Those projects did not exist in that state for long.
>>
>> Why in the world would it matter that different people use different
>> editors or IDEs? That makes no sense.
>>
>> I have worked on teams for years where people used different IDEs and
>> editors. It didn't cause problems unless either management objected
>> (never for any solid engineering reason) or people checked IDE artifacts
>> into source control.
>>
>> There's absolutely nothing wrong with each team member using a different
>> editor or IDE, and much right.
>>
> Often enough - we are not necessarily discussing vanilla Java
> development here - one IDE will do certain tasks better (maybe much
> better) than other IDEs. These certain tasks are required by the job at
> hand. Rather than allow some aficionado of IDE X to flail away trying to
> make something work, when it would definitely work easily in IDE Y, you
> simply step in as the team lead and mandate IDE Y.

I've never seen a situation where this was actually true, except for Mac and iOS development via Xcode.

I acknowledge that it's theoretically possible.

> As for IDE artifacts in source control, there is nothing wrong, IMO,
> with checking in non-workstation-specific project configurations. I've
> seen this practise, for example, substantially reduce the time needed to
> get new devs up to speed. This can also be used to communicate other
> standardizations, rather than having people read a wiki someplace and
> manually set up team-mandated settings in their IDEs.

The key is "non-workstation-specific", and is largely unnecessary for Java projects anyway.

The major IDEs work just fine off command-line/scripted project builds using Ant or Maven or simply analyzing the code in the project. I've had substantial experience doing this with both NetBeans and Eclipse and have no issue with either IDE's handling of "new project from existing code".

I do approve of checking in IDE artifacts to branches in the repository, but not the main build trunk. The trunk should comprise only scripts and source.

IDE stuff in the branches makes life beautiful - you get the avowed advantages of quick ramp-up and you can even set up branches for every IDE in the shop. However, again, this should be unnecessary with IDEs that read Ant and Maven build scripts.

> This is obviously a hotly debated topic. There are quite a few Stack
> Overflow threads dealing with it, and a mix of opinions. Some
> vociferously argue for only source and libraries, others argue like me.
> Some who are in the "no config files" camp also argue for using Maven to
> generate these files: this is where my prejudices show, because I
> dislike Maven and wouldn't urge its use on anyone.

I hate Maven, too.

> You're right, sort of - there isn't anything inherently wrong, as a
> rule, with team members using different IDEs...except when circumstances
> don't promote that freedom of choice.

The only circumstances that don't promote that freedom of IDE choice that I've encountered involved ukases from management without anywhere near the degree of logic and rational foundation you've presented.

No one has ever presented a scenario to me in the years I've tracked this debate that gave shared IDE artifacts the win. On the other hand, one major project (involving over a million lines of code and another million of XML) mandated shared Eclipse (well, Rational Developer) project files, that had to be hand-converted to Ant scripts by the deployment team for every build. When the project upgraded to a new version of the IDE it took more manhours and more calendar weeks to fix the IDE project files team-wide than it did to upgrade the project from Java 1.4 to Java 5 around the same time. The shared IDE files were a major problem for the project.

So no clear case for mandated IDE that I've ever seen or even heard of, several clear cases I've seen where that practice caused damage.

Check the IDE files into a branch and my objections vanish like smoke.

--
Lew

[Arved Sandstrom]

On 12-04-26 07:02 PM, Lew wrote:
> Arved Sandstrom wrote:
>> Lew wrote:
>>> Robert Tomsick wrote:
>>>> I've worked on projects where different members of the team used
>>>> different
>>>> IDEs. Those projects did not exist in that state for long.
>>>
>>> Why in the world would it matter that different people use different
>>> editors or IDEs? That makes no sense.
>>>
>>> I have worked on teams for years where people used different IDEs and
>>> editors. It didn't cause problems unless either management objected
>>> (never for any solid engineering reason) or people checked IDE artifacts
>>> into source control.
>>>
>>> There's absolutely nothing wrong with each team member using a different
>>> editor or IDE, and much right.
>>>
>> Often enough - we are not necessarily discussing vanilla Java
>> development here - one IDE will do certain tasks better (maybe much
>> better) than other IDEs. These certain tasks are required by the job at
>> hand. Rather than allow some aficionado of IDE X to flail away trying to
>> make something work, when it would definitely work easily in IDE Y, you
>> simply step in as the team lead and mandate IDE Y.
>
> I've never seen a situation where this was actually true, except for Mac and iOS development via Xcode.
>
> I acknowledge that it's theoretically possible.

It's absolutely possible. We've had this discussion. Depending on what
your specific needs are you may find that one, some, all or none of
Eclipse, NB and IDEA do the trick for a given job.

Nothing is impossible in any IDE, of course. But for some jobs you may
find that one IDE is all tooled up, where another isn't much more than a
text editor with no "awareness".

Just in the last 6 months, with one project involving VB6, another
involving a very non-standard project in C and C++ (non-standard in all
ways, you would not believe), and another involving Oracle Forms, and
yet another involving Pascal written with IDE artifacts specific to one
Pascal IDE, I can think of 4 cases easily where there was a very obvious
and common-sense IDE choice. Other choices ultimately could have been
made to work, but with some degree of unnecessary effort.

>> As for IDE artifacts in source control, there is nothing wrong, IMO,
>> with checking in non-workstation-specific project configurations. I've
>> seen this practise, for example, substantially reduce the time needed to
>> get new devs up to speed. This can also be used to communicate other
>> standardizations, rather than having people read a wiki someplace and
>> manually set up team-mandated settings in their IDEs.
>
> The key is "non-workstation-specific", and is largely unnecessary for Java projects anyway.

Well, if you're not sharing IDE config files there's nothing to worry
about. If you _are_, you probably don't want your buddy's colorizing and
font choices foisted on you. Some developers swear by their choices in
this regard; I'm not particularly fanatical but I do like my chosen font
and microscopic point size. :-)

> The major IDEs work just fine off command-line/scripted project builds using Ant or Maven or simply analyzing the code in the project. I've had substantial experience doing this with both NetBeans and Eclipse and have no issue with either IDE's handling of "new project from existing code".
>
> I do approve of checking in IDE artifacts to branches in the repository, but not the main build trunk. The trunk should comprise only scripts and source.
>
> IDE stuff in the branches makes life beautiful - you get the avowed advantages of quick ramp-up and you can even set up branches for every IDE in the shop. However, again, this should be unnecessary with IDEs that read Ant and Maven build scripts.

We're on the same sheet of music here. I'm talking IDE artifacts for
developers, on developer branches.

Most organized places I've worked have developer branches, test
branches, and production branches. Test and production don't care about
IDEs, and as you note you're talking build scripts and automation here.

>> This is obviously a hotly debated topic. There are quite a few Stack
>> Overflow threads dealing with it, and a mix of opinions. Some
>> vociferously argue for only source and libraries, others argue like me.
>> Some who are in the "no config files" camp also argue for using Maven to
>> generate these files: this is where my prejudices show, because I
>> dislike Maven and wouldn't urge its use on anyone.
>
> I hate Maven, too.
>
>> You're right, sort of - there isn't anything inherently wrong, as a
>> rule, with team members using different IDEs...except when circumstances
>> don't promote that freedom of choice.
>
> The only circumstances that don't promote that freedom of IDE choice that I've encountered involved ukases from management without anywhere near the degree of logic and rational foundation you've presented.
>
> No one has ever presented a scenario to me in the years I've tracked this debate that gave shared IDE artifacts the win. On the other hand, one major project (involving over a million lines of code and another million of XML) mandated shared Eclipse (well, Rational Developer) project files, that had to be hand-converted to Ant scripts by the deployment team for every build. When the project upgraded to a new version of the IDE it took more manhours and more calendar weeks to fix the IDE project files team-wide than it did to upgrade the project from Java 1.4 to Java 5 around the same time. The shared IDE files were a major problem for the project.
>
> So no clear case for mandated IDE that I've ever seen or even heard of, several clear cases I've seen where that practice caused damage.

That was a problem with mandating the sharing of Rational Developer
config files, not necessarily with requiring the uniform use of Rational
Developer. No?

> Check the IDE files into a branch and my objections vanish like smoke.
>

I've seen both good and bad situations result from sharing IDE
artifacts. It's quite dependent on knowing your IDE artifacts if you go
down the road of committing selected IDE files. I've seen some disasters
or just annoyances myself where folks didn't know what they were
checking in. This might range from using absolute paths in an IDE config
file that otherwise would be an OK choice to place under source control
(an annoyance to others) to committing config files that never ought to
have been considered (always a PITA and sometimes really frustrating).

To be fair I've also seen bad situations resulting from sharing Ant
build files and requiring those. One example comes to mind: a guy who
otherwise knew Ant quite well, and was one of the few to make
substantive changes to a particular project's build scripts, mainly
because most of the devs didn't know Ant that well. Just so happened
that buddy made some tweaks and went home for the weekend with a
vacation after. The tweaks were ill-advised and not sufficiently tested,
not at all by anyone except the original editor. That caused some
anguish start of the next work-week.

No, it wasn't me: I don't get vacations.

Just sayin'. Anything can be made to work...or not work. Although my
objections to Maven still stand. :-)

Let's be clear: I am no more _recommending_ IDE artifacts under source
control, across the board and for everyone, than I'd recommend that
everyone universally use Ant or Maven.

[Lew]

Arved Sandstrom wrote:
> Lew wrote:

>> Arved Sandstrom wrote:
>>> Often enough - we are not necessarily discussing vanilla Java
>>> development here - one IDE will do certain tasks better (maybe much
>>> better) than other IDEs. These certain tasks are required by the job at
>>> hand. Rather than allow some aficionado of IDE X to flail away trying to
>>> make something work, when it would definitely work easily in IDE Y, you
>>> simply step in as the team lead and mandate IDE Y.
>>
>> I've never seen a situation where this was actually true, except for Mac and iOS
>> development via Xcode.
>>
>> I acknowledge that it's theoretically possible.
>
> It's absolutely possible. We've had this discussion. Depending on what
> your specific needs are you may find that one, some, all or none of
> Eclipse, NB and IDEA do the trick for a given job.
>
> Nothing is impossible in any IDE, of course. But for some jobs you may
> find that one IDE is all tooled up, where another isn't much more than a
> text editor with no "awareness".
>
> Just in the last 6 months, with one project involving VB6, another
> involving a very non-standard project in C and C++ (non-standard in all
> ways, you would not believe), and another involving Oracle Forms, and
> yet another involving Pascal written with IDE artifacts specific to one
> Pascal IDE, I can think of 4 cases easily where there was a very obvious
> and common-sense IDE choice. Other choices ultimately could have been
> made to work, but with some degree of unnecessary effort.

None of those are Java, so I don't guess I'd pick NetBeans or Eclipse for any of those scenarios. For the C, C++ situation I'd likely opt for emacs.

I was talking about Java projects, but I see how in the cases you describe a given IDE might not help. But since this is a Java newsgroup I'd like to hear of examples pertinent to Java development.

>>> As for IDE artifacts in source control, there is nothing wrong, IMO,
>>> with checking in non-workstation-specific project configurations. I've
>>> seen this practise, for example, substantially reduce the time needed to
>>> get new devs up to speed. This can also be used to communicate other
>>> standardizations, rather than having people read a wiki someplace and
> >> manually set up team-mandated settings in their IDEs.
>>
>> The key is "non-workstation-specific", and is largely unnecessary for Java projects anyway.
>
> Well, if you're not sharing IDE config files there's nothing to worry
> about. If you _are_, you probably don't want your buddy's colorizing and
> font choices foisted on you. Some developers swear by their choices in
> this regard; I'm not particularly fanatical but I do like my chosen font
> and microscopic point size. :-)

Exactly so. This is part of why I suggest not sharing IDE files in the project trunk.

In large-scale projects or ones with team-member churn, you can count on such fubars if you
permit checking IDE files into the trunk.

> To be fair I've also seen bad situations resulting from sharing Ant
> build files and requiring those. One example comes to mind: a guy who
> otherwise knew Ant quite well, and was one of the few to make
> substantive changes to a particular project's build scripts, mainly
> because most of the devs didn't know Ant that well. Just so happened
> that buddy made some tweaks and went home for the weekend with a
> vacation after. The tweaks were ill-advised and not sufficiently tested,
> not at all by anyone except the original editor. That caused some
> anguish start of the next work-week.
>
> No, it wasn't me: I don't get vacations.
>
> Just sayin'. Anything can be made to work...or not work. Although my
> objections to Maven still stand. :-)
>
> Let's be clear: I am no more _recommending_ IDE artifacts under source
> control, across the board and for everyone, than I'd recommend that
> everyone universally use Ant or Maven.

I do recommend that Java projects universally use Ant, though by "universally" and "always" I never mean universally or always (and never mean never by "never"). Maven blows chunks and nothing else works as well.

I do not recommend using *only* Ant for builds and deployment. Feel free to add glue scripts (bash, Python, whatever), as indicated by circumstances.

I suggest that your colleague's ill-advised changes should have undergone the rigors of review and test before commitment that all code changes must undergo. The problem wasn't with Ant there, any more than it would have been Java's fault if they'd changed Java code, failed to test it adequately or even to have it reviewed, checked it in, and disappeared.

But your examples are telling, if not pertinent to Java. Have you more to say on this specific to Java projects?

--
Lew

[Robert Tomsick]

On Thu, 26 Apr 2012, Arved Sandstrom wrote:

> On 12-04-26 11:30 AM, Lew wrote:
>> Robert Tomsick wrote:
>>> I've worked on projects where different members of the team used
>>> different
>>> IDEs. Those projects did not exist in that state for long.
>>
>> Why in the world would it matter that different people use different
>> editors or IDEs? That makes no sense.
>>
>> I have worked on teams for years where people used different IDEs and
>> editors. It didn't cause problems unless either management objected
>> (never for any solid engineering reason) or people checked IDE artifacts
>> into source control.
>>
>> There's absolutely nothing wrong with each team member using a different
>> editor or IDE, and much right.
>>
> Often enough - we are not necessarily discussing vanilla Java
> development here - one IDE will do certain tasks better (maybe much
> better) than other IDEs. These certain tasks are required by the job at
> hand. Rather than allow some aficionado of IDE X to flail away trying to
> make something work, when it would definitely work easily in IDE Y, you
> simply step in as the team lead and mandate IDE Y.

I didn't mean to imply that it was necessary to ban the practice nor that
the cases I had in mind were ended with a mandate.

The above is a pretty good explanation of what happened in the two cases
that I have in mind. In the most recent one it was an issue of support
for a particular plugin which was useful to the team; the plugin existed
for Eclipse and worked beautifully there. Could somebody have done their
job with NetBeans? Sure. But they'd be basically using it as a dumb text
editor for the formats that the plugin offered full tool support for, and
as a result would take longer to do the same tasks.

This does sorta go along with the "pick the right tool for the job" thing,
but yeah, that's pretty much what I had in mind. In both cases, BTW, the
developer(s) in question switched without being forced to.

I agree though: for plain Java projects there's really not any major
downside that I can think of to using different IDEs except for the whole
IDE-artifacts bit mentioned elsewhere in this thread. And perhaps an
increase in internal documentation, etc... but that obviously depends on
the business.

-R

[Arved Sandstrom]

On 12-04-26 08:31 PM, Lew wrote:
[ SNIP ]

>
> I do recommend that Java projects universally use Ant, though by "universally" and "always" I never mean universally or always (and never mean never by "never"). Maven blows chunks and nothing else works as well.
>
> I do not recommend using *only* Ant for builds and deployment. Feel free to add glue scripts (bash, Python, whatever), as indicated by circumstances.
>
> I suggest that your colleague's ill-advised changes should have undergone the rigors of review and test before commitment that all code changes must undergo. The problem wasn't with Ant there, any more than it would have been Java's fault if they'd changed Java code, failed to test it adequately or even to have it reviewed, checked it in, and disappeared.
>
> But your examples are telling, if not pertinent to Java. Have you more to say on this specific to Java projects?
>

For Java projects (SE or EE) I wouldn't myself usually much care who
uses what IDE. The only caveats I have there are that each developer be
quite proficient with the IDE that they pick (rather than choosing
company time to experiment with an unfamiliar one), and that if a novice
programmer is not really all that proficient with any IDE that they
select one that most of the team is using.

The main rule I have in team environments involving intermediate or
senior people is that you get to pick your tools until such a time as
you demonstrate that you're wasting team time by trying to make
something inferior work. At which point you get told what you're going
to use. I've been down that road numerous times, sometimes with me being
the guilty party.

I'm with you on Ant. One may as well do this, you want a build script
for CI anyhow.

[Roedy Green]

On Thu, 19 Apr 2012 16:35:24 -0400, Steve <tink...@gmail.com> wrote,
quoted or indirectly quoted someone who said :

>So, what are the big differences between the two that make some people
>go with one and others with the other?

There is a third one, IntelliJ Idea.

Eclipse has all kinds of add-ins. Eclipse is free.

Idea is the fastest. Idea gives you lots of flexibility in how you
structure projects, and generated executables. It is a commercial
product so they are very polite when you ask dumb questions.


Netbeans does visual layouts. It is has a very simple notion of
project structure. It was a no-go for me. My projects are far too
complex for its paradigm but it is a lot easier to understand.


See http://mindprod.com/jgloss/ide.html for some more things to
consider. In a way though you are asking us to recommend you a wife.
The is no substituted for a test drive. It depend as much on you as
the IDE which is the best fit. Try building a tiny project from
scratch with each.

--
Roedy Green Canadian Mind Products
http://mindprod.com
Programmers love to create simplified replacements for HTML.
They forget that the simplest language is the one you
already know. They also forget that their simple little
markup language will bit by bit become even more convoluted
and complicated than HTML because of the unplanned way it grows.
.

[Roedy Green]

On Thu, 26 Apr 2012 07:30:59 -0700, Lew <no...@lewscanon.com> wrote,

quoted or indirectly quoted someone who said :

>Why in the world would it matter that different people use different editors
>or IDEs? That makes no sense.

It would not matter if you all used a common code beautifier before
checkin. One way to simply enforce that is all to use the same IDE
with the same beautify/reformat/rearranger config.

[Roedy Green]

On Thu, 26 Apr 2012 07:30:59 -0700, Lew <no...@lewscanon.com> wrote,
quoted or indirectly quoted someone who said :

>Why in the world would it matter that different people use different editors
>or IDEs? That makes no sense.

It would also matter if the employer provided the IDE. If it were
IntelliJ for example, they can get a bulk discount on multiple copies.
If every programmer got to pick his own, it could be more expensive.

It would also matter if you had a team with mixed levels of skill
where more senior people would help junior with IDE use problems.
You want everyone on the same page.

The tendency now is to compose international teams scattered over the
globe where each member is fully responsible for his computer and
tools.

[Steve]

On 5/9/2012 10:11 PM, Roedy Green wrote:

>
> Idea is the fastest. Idea gives you lots of flexibility in how you
> structure projects, and generated executables. It is a commercial
> product so they are very polite when you ask dumb questions.

I don't believe there is such a thing as a "dumb question".

Happy Tuesday

Steve

[Steve]

On 5/9/2012 10:11 PM, Roedy Green wrote:

> On Thu, 19 Apr 2012 16:35:24 -0400, Steve<tink...@gmail.com> wrote,
> quoted or indirectly quoted someone who said :
>
>> So, what are the big differences between the two that make some people
>> go with one and others with the other?
>
> There is a third one, IntelliJ Idea.
>
> Eclipse has all kinds of add-ins. Eclipse is free.

I've been going on the non-free route for years, with Visual Slickedit.

Money isn't the issue.

I was asking about Eclipse and Netbeans because it seems to be what most
Java developers are using and I think there would be advantages for me
in using tools that many, many other people are using.

Steve