Return of the JDEE

Over the past year, I have been using Eclipse, the free and very popular open-source Java IDE, along with commercial plugins provided by MyEclipse. Prior to that, I was (and still am, for non-Java coding and editing), a vim user. I totally missed the boat on EMACS, much like I missed the boat on C++ (went directly from C to Java), or more lately, "classic" J2EE with EJBs (went from plain servlet programming to POJO based frameworks). In fact, my first job out of college was as a Software field support engineer with a computer manufacturing company which sold midrange Unix systems, so you could say I practically cut my teeth on vi (the predecessor of vim).

I have always been interested in learning EMACS, however, because it seemed to be the IDE/editor of choice for the uber-geeks among my colleagues before they switched to their favorite Java IDEs. I noticed that they would use emacs for as many things as they could, from writing code to reading email, running shell commands, etc. In retrospect, it could be because of the long startup times for emacs on the comparitively memory bound systems that were in use at the time. So when I switched to Eclipse, I changed the editor key-bindings from the default CUA Windows-style to EMACS mode, figuring that this would give me a head start on getting my fingers used to EMACS commands.

EMACS has been vilified as "Eight Megabytes And Constantly Swapping" because of its comparitively high memory requirements. I recently looked at the Eclipse memory footprint on my workstation and compared it to the footprint of an equivalent EMACS, and they weighed in at 100MB and 20MB respectively. So, not surprisingly, EMACS consumes fewer resources than standard IDEs in use today. The question remains - does it offer similar functionality to the Java programmer?

As it turns out, there is a comprehensive and free Java plugin suite for emacs, called JDEE. I was pretty impressed with the JDEE feature set, so I decided to install it and take it out for a spin. This article provides some resources on how to install JDEE, and compares JDEE features to corresponding Eclipse features. I also highlight Eclipse functionality that I missed in JDEE.

Installing JDEE

Assuming you are running a stock Linux distribution, you should already have EMACS or XEMACS installed. If you are new to EMACS, be aware that most of the customization and features are provided by EMACS-Lisp (.el) files in your site-lisp directory, (in my case, ~/.emacs.d), which are invoked from your EMACS startup file (~/.emacs).

JDEE requires quite a few plugins to work, they are listed on the Installing the JDEE page. This is quite a bit of work, but fortunately, you can use Artur Hefczyc's script to do this with a single command. It seems to be a little out of date, however, since I had to upgrade the cedet and jde packages to the latest ones to make JDEE work.

I used Artur's .emacs and prj.el files as a starting point. He is a long time EMACS user, so he has references to various external plugins in his .emacs file which will show up as error messages in EMACS when it is started up. Fortunately, he has been very good about documenting the websites where he downloaded his sources in his .emacs file, so it was a simple matter to go to these sites and download the .el files, and install them into my ~/.emacs.d/site-lisp directory. The only one I could not do was color-themes.el, but since his default color scheme worked fine for me, this wasn't an issue.

Setting up the JDEE

EMACS/JDEE dependencies that are needed for Java programming need to be set up in a prj.el file. This is similar to the .prefs file in Eclipse, and can either be set up for all your projects or separately for each project. Overriding is by directory hierarchy, so your "global" prj.el may be in your home directory, and a project specific prj.el file for a project located at ~/src/myproject would be in ~/src/myproject/prj.el. The settings in the project specific prj.el will override corresponding settings in the global prj.el. Settings include standard boilerplate templates, your source and class paths, the JDK compiler you are using, coding standards such as tab width, import style, etc. Artur provides his prj.el file on his site, which can be used as a base for customizing it to your environment.

Faceoff: JDEE vs Eclipse

One of the things that prompted me to look at JDEE is that, unlike other developers I know, I tend to not do everything in the IDE. For example, I rarely build code or run JUnit tests from within the IDE, I rely on Ant build scripts instead, which I run from a terminal window. I also prefer interacting with the source code repository (CVS in my case) using the command line rather than the GUI based interface provided by the IDE. To access various databases, I prefer using the command line clients provided by the database vendor rather than use the MyEclipse SQL Explorer feature. I also prefer using Eclipse keyboard shortcuts over mouse-based point and click interaction. So I figured, so what if JDEE does not provide all the features that Eclipse has? For my comparison, I only concentrate on the features I need and use myself.

• Moving around: Moving around the editor in both systems is similar, since I already use EMACS key bindings in Eclipse.
• Selecting a JDK: Both Eclipse and JDEE can specify a JDK (Java 1.5 versus Java 1.4, for example) per project. You set this up in Eclipse in Project Properties and in the jde-jdk (Mx jde-jdk) customization buffer in EMACS/JDEE.
• Opening type/resource: Eclipse can open a Java file using CT and non-Java files using CR. JDEE can open a Java file using Mx jde-open-class-source command. For finding resource files, I think you will have to revert to using Unix find or use the JDEE Speedbar (Cv Cc Cs).
• Cross reference files: Hitting F3 on a class or variable declaration in Eclipse allows you to go to the source or generated Javadoc (if no source is available) of that declaration. EMACS/JDEE uses etags to do the same thing, although you will need to set up a cross-reference database for this.
• Code Templates: Like Eclipse, EMACS/JDEE offers code templates for new class and interface files, wizards for get/set, listener, delegate and abstract class extension methods, package generation wizards, organizing imports, etc. These are available in Eclipse under the Source menu and in EMACS/JDEE under the JDE/Code Generation menu.
• Autocompletion: In Eclipse, you can press M/ to see a list of suggested completions for your statement. With EMACS/JDEE, the command sequence is Cc Cv C-.
• Inline error reporting: I am referring to the red or yellow squigglies under the offending peice of code, depending on whether it is a error or warning, possibly inspired by the MS-Word spellcheck feature we have all grown to know and love. I could not find an equivalent functionality in EMACS/JDEE.
• Code suggest: Eclipse sometimes provides suggestions (via the lightbulb icon) on better ways to do the same thing. This is also not available in EMACS/JDEE as far as I could see.
• Support for non-Java languages: EMACS obviously leads on this one, having been around longer. I suspect its also easier to build new editor plugins with E-LISP than with the Eclipse plugin architecture, although this is pure speculation on my part, having never developed either an E-LISP EMACS plugin or an Eclipse plugin.
• Ability to edit remote files: This is more of an EMACS feature than an Eclipse one. You can connect to a remote computer over ssh and use a local (text-based) EMACS to edit the remote file. Of course, this is not an option with Eclipse.

The closest analogy I can think of when comparing Eclipse and EMACS/JDEE is the difference between a car with automatic transmission (Eclipse) and one with manual (EMACS/JDEE). In the hands of the right driver (or programmer), both are equally powerful and functional. Unfortunately, while IDEs provide you the tools to write code more rapidly, they also help atrophy skills that you had to have before and now you no longer need to. When I wrote my code with vim, I would spend more time ramping up with new libraries, but at the end of the project, knew my libraries much better because I had actually spent time reading the Javadocs and playing around with wrong combinations. Nowadays, most of the time I do a M/, look through the list of method names, and choose the one which looks right. Of course, it also meant that I would restrict myself to using fewer libraries to begin with.

Now for the million dollar question. Would I switch from Eclipse to EMACS/JDEE? I dont think I am ready to do this just yet. Like other programmers who did not grow up with IDEs, I recognize that my use of IDEs has made me lazier and less of a programmer than I used to be. I am also a relative EMACS newbie, so I would need to gain more expertise with EMACS to consider switching. However, one place where I plan to use EMACS/JDEE is when I am working from home remotely on my desktop at work. I have written previously about using rsync to do this, but I think that this may be a better way. I am also beginning to use EMACS more and more for non-Java work, such as when I am writing Python scripts.