Yes, JDEE is an Emacs extension package.  The implementation is about
half in Java and half in Emacs Lisp.  If you like using Emacs, and are
doing Java development, then JDEE is surely a no-brainer.  You'll like
it.

For example, it does useful things such as method completion: you type
x.get and then a key combo and it figures out which methods from the
class x comes from start with "get".  Other IDEs have been doing this
for a while now, but there are other advantages to using Emacs...

JDEE also has integrated Ant support.  You press a key, it invokes Ant
in the right directory to build your project.  Then it jumps to the
first compiler error, if any.

You might also like to use ECB (Emacs Code Browser) together with
JDEE.  They complement each other well.  ECB provides various
informational kinds of windows, such as a directory browser and a list
of methods in the current class, and so on.

If you have never used Emacs before, be prepared.  It's maybe quite
different from other pieces of software.  Its charms are not
apparent.  They need time to be appreciated.

(But that said, I've now been using Eclipse for a couple of weeks, and
we're not really well acquainted yet.  So maybe it's not more
difficult to start using Emacs (productively) than to start using
Eclipse productively.)

Does this help?

Kai

   William> has anyone used jdee before? does it work with emacs as
   William> it claims? what is the experience with setting it up?
   William> could anyone shed some light about the experience with
   William> jdee?

You should send this query to the JDEE mailing list (jde@sunsite.dk),
which has more than 600 subscribers some of which are companies and
universities.

Paul

Yes.  

Very well.

It is like anything else in Emacs.  Once you've integrated any
external package, integrating the JDEE is analogous.

My experience is from another angle.  Being an Emacs user for
most everything I do, I've found the JDEE to be a very useful
tool.  I'm a database architect but my published interface to the
J2EE middle-tier is (homegrown) Data Access Objects.  My database
team must maintain these daos making sure the application doesn't
break as we move forward with development.  In doing this, I've
had to visit and rewrite some of the middle-tier code base along
with my team having ownership of the dao layer.  The JDEE has been
invaluable in these tasks.

If one describes the JDEE without describing Emacs, then one gets
alot of "so what, my software does that particular set of tasks".
Its when one puts all of Emacs together and describes that, Emacs
becomes an _extremely_ powerful tool.  If you describe the JDEE,
most all of its functionality is also found in other
environments.  The fact that the JDEE works within Emacs makes it
just another very nice tool for an Emacs user.  You get a Java
Development Environment within Emacs.  I don't have to leave my
Emacs controlled sqlplus session to compile, fix and debug the
daos I need to maintain.  I just hop there and back, checking each
critical sections of the app all within my integrated
Environment.  And, oh, btw, I interact with CVS throughout the
day, cause that is just a couple of keystrokes away as well, and
I hop directly into the docbook documentation source while coding
and I post code findings to newsgroups, and I maintain my suite
of dba scripts and I maintain the ant build scripts ...  (See
what I mean, an Emacs user just goes on and on.  Its Emacs that
he is describing, not the JDEE)