Tom said:
Arne said:
desktop apps => Eclipse IDE for Java Developers
server apps => Eclipse IDE for Java EE Developers
Roughly. AIUI, the SQL support is in the EE edition, but not the standard
edition. If you want to use SQL on the desktop, you might like to get the EE
edition.
The EE edition is basically the standard edition with more perspectives and
views. I [sic] don't believe it alters anything that's in the standard edition. So,
if you can spare the disk space, i would suggest getting the EE edition, so
you have a pretty complete Java development environment, even if you don't use
much of the EE bits. You never know, at some point, you might want to write a
little web application.
If you don't have the disk space for the EE edition, you don't have enough
disk space to do Java development. Just get the EE edition.
Although, having said all that, i would suggest not starting with an IDE, or
at least not one of any complexity. An editor with automatic indentation and
syntax highlighting will do; TextWrangler is good, and actually, XCode is a
pretty good Java editor, even if it is lacking as an IDE.
This is controversial advice. The merit of command-line builds is that you
learn your stuff. The downside is you get off to a slightly slower start. I
concur that it is worth the effort to master using Java from the command line.
"What?" you ask. "Who said anything about command line?" Well, if you take
Tom's advice and avoid an IDE, your editor won't do builds, debugging,
classpath management, syntax-checking, expression completion or all the little
Java niceties that the IDEs provide. You also lose the dashboard for resources
like database systems, web servers, application servers, build profiles and
such. You will have to use the command line to build your systems, i.e., the
"java" and "javac" commands, Ant or Maven.
If you use an IDE like NetBeans or Eclipse then you get all that assistance
and convenience, but you might get sloppy in your learning.
I favor a third approach. Use an IDE, but always check your work with a
command-line build in a separately checked-out workspace (you MUST use version
control ALWAYS, even on solo projects). I've worked on major projects
(big-iron Federal systems) where the command-line build differed significantly
from the developers' Eclipse-based ones, and it took two people two days for
each release to convert the Eclipse build data for the official build. If you
find a discrepancy between your IDE build and your command-line build, fix the
former to match the latter. Builds should never rely on a particular IDE or
editor.
As for which editor to use, vi and emacs are just fine in the modern world if
you do eschew an IDE. Which I wouldn't.
