Thanks.
humm.... i should say not yet. For a lot of jobs here in Canada,
you need to be familiar with Eclipse. I haven't figured out the reason
yet but I happen to be more familiar with Eclipse. ^^;)
> For a lot of jobs here in Canada,
> you need to be familiar with Eclipse. I haven't figured out the reason
> yet but I happen to be more familiar with Eclipse. ^^;)
Why the heck do so many managers seem bent on mandating IDEs? I have worked
in many places where Eclipse was the "standard" IDE for Java, but I cheerfully
went ahead and used Netbeans (and emacs) to do my source development. Only
when people have absolutely insisted that I must use Eclipse (I still don't
know how they justified that) did I do so, and then only because I like
getting a paycheck.
It's not that I dislike Eclipse very much, only that I prefer Netbeans. I
have also used JBuilder and WSAD (IBM's WebSphere Application Developer) when
someone else paid for the licenses.
The choice of IDE is, or should be, completely immaterial to the finished
product. The ultimate deployment environment is command-line, with Ant. Any
editor from vi on is fine if you can be productive with it.
Furthermore, if all developers on a project use only one IDE, there is
significant risk of dependencies on that IDE creeping into the build. I feel
that Eclipse is especially vulnerable here; it does rather clever things with
classpaths that let a program run within the IDE, only to fail when you leave
Eclipse's hearth. Testing should always occur on a command-line build
(preferably with Ant) before release.
That said, the earlier post about using an editor to insert a main() is not
such a joke.
We should get to pick our own editors; forcing standardization on a single IDE
in a project is an error.
- Lew
Chris Uppal - 30 Nov 2006 12:56 GMT
> Why the heck do so many managers seem bent on mandating IDEs?
I can think of a couple of reasons.
One (bad, but plausible) is that the project had /already/ become dependent on
the IDE.
Another (much better) is that knowledger dissemination within a team works much
better if everyone needs (roughly) the same knowledge.
One particularly extreme instance of the latter point is that some programmers,
if they don't know how to do something, will simply not do it. If you have
someone(s) like that on your team then it's vital that there be other people on
the team who can show them "its easy, see, just do <whatever>". (Such people
aren't necessarily bad programmers otherwise, but they can be damaging if left
uncontrolled.)
I'm not suggesting there aren't downsides too -- one that would concern me
about Eclipse specifically is that it uses its own compiler instead of javac.
-- chris
Mark Jeffcoat - 30 Nov 2006 19:08 GMT
> Furthermore, if all developers on a project use only one IDE, there is
> significant risk of dependencies on that IDE creeping into the build.
> I feel that Eclipse is especially vulnerable here; it does rather
> clever things with classpaths that let a program run within the IDE,
> only to fail when you leave Eclipse's hearth. Testing should always
> occur on a command-line build (preferably with Ant) before release.
It's not obvious to me that being dependent on Eclipse is
really a problem, as long as you're still able to deploy
the project into its production environment. It's not like
Eclipse is going to go away.
(I do all my programming in Emacs. I've had to learn quite
a lot about Ant just so I could play with the Eclipse people.)

Signature
Mark Jeffcoat
Austin, TX
David Segall - 01 Dec 2006 15:24 GMT
>Why the heck do so many managers seem bent on mandating IDEs?
>
>The choice of IDE is, or should be, completely immaterial to the finished
>product. The ultimate deployment environment is command-line, with Ant.
I don't agree that it "should" be. It is, for example, possible to
write a GUI in Java. It is also possible to write the GUI in the "high
level language" provide by any of several IDEs. I prefer to use the
latter despite the fact that it is not portable between IDEs.
>We should get to pick our own editors; forcing standardization on a single IDE
>in a project is an error.
There is a raft of tools that come with an IDE. Many provide developer
collaboration including bug tracking, source code control and project
management. I don't think it is an "error" to enforce standards by
mandating an IDE.