I decided to try some of the most known Java IDE on the market to see which one would work better for me: the idea was to install each IDE and work with it for at least a week on a real project, to test if I could adapt to a new IDE and the IDE could adapt to my working patterns in a relatively short time and in a “real world” situation. I wanted a comparison that made sense to me at this time and in the context of this particular project, not trying every single feature of each IDE: I wanted to test
- editing and refactoring code
- cvs integration
- configurability (how much the IDE can adapt and how much it gets in my way of working)
- remote debugging
- speed of operation
I didn’t care at all about Web services, JUnit integration, JSF support, etc.: all of this does not matter to me at this particular time.
Setup and constraints
The setup on this project is a little unusual, but there are good reasons for it: the IDE runs on my laptop, where the code being edited and ran is on another workstation, mounted as a Windows shared drive (Z:\) on the laptop. The code is a multi-module ATG application, consisting of about several hundreds of Java classes, properties files and JSP pages: all the files are kept in a CVS server, and the CVS working directory is also the ATG module directory so that only one copy of each file exists at any given time. IDE-specific project files should not go into CVS, to avoid conflicts between workstations with different path names.
Despite my good intentions, Eclipse did last only half a day… I had configured my workspace and the project files on drive D:\, then attempted to configure the project source folders via the Link Source feature: it worked fine up to the point of checking out the sources from CVS, when I discovered that Eclipse is unable to check out/check in. There is a long standing bug that apparently won’t be fixed.
This is a pity, because Eclipse is a decent tool despite its shortcomings and many inconsistencies (often debugging cannot “see” the project sources, 2 or 3 different perspectives to work with source control, etc.). I tried to run it on the workstation, but adding it to the 3/4 ATG instances already running was asking too much to the hardware.
NetBeans was more willing to cooperate with my setup, and it lasted a whole week of intense work. Nothing much to say about the CVS integration and the project organization, at least it allowed me to place the files where I wanted them to be; the speed of the IDE was something I could live with, even if not extraordinary, but the editor had its own share of problems:
- at first I could not find how to generate getters and setters for a class member variable, then I found I must select the variable and choose Refactor > Encapsulate Field: I found that counterintuitive but acceptable, I could not accept however that it didn’t respect the code conventions I configured (“m” prefix for member variables, “p” prefix for parameters)
- saving a file took 30 seconds on average, probably due to the working directory being on a shared drive and the IDE trying to synchronize too many files in the proceeding
- the JSP code assistance produced weird code, for example I typed <dsp:param name=”propertyName” value=”phoneNumber”/> and then Enter, and it added a </dsp:param> that makes no sense
- after writing a Java method will all of its parameters and return type, typing “/**” to start a javadoc comment does not generate the @param and @return tags
- very often the remote debugger didn’t work, in many cases I couldn’t get the local variables of a method (Evaluating… was displayed for minutes in the debugger panel) and in some other cases it hung up the whole IDE (the only recurse was force-quitting it)
- once, after an intense, day-long editing session I had an icon flashing in the lower-right corner of the IDE window with a “too many window handles” message: switching between Windows process with Alt-Tab gave weird results, with windows flashing all over the screen, and in NetBeans I couldn’t do anything; in the end I had to kill it
So NetBeans was better than Eclipse in my situation (I could at least *use* it to work) and it didn’t have many of Eclipse’s interface annoyances: however I didn’t find it good enough to keep working with it.
I spent more time setting up a project with JDeveloper than with the other IDEs as I didn’t understand at first the system and application navigators: what I want is see the files as they are laid out on disk, and only then maybe overlay a custom view on top. I discovered in the end that setting the “flat level” to 1 in the application navigator came close to what I want. I liked the structure panel of the JSP editor, but I couldn’t find an option to open JSPs by default in the source editor rather than in the visual editor, which was useless to me; saving files was even slower than in NetBeans and refactoring was sometimes bizarre (renaming a dynamohttpservletrequest method parameter to pReq produced invalid syntax…).
I don’t have much else to say about JDeveloper because in the end it lasted less than one day… In a couple of occasions it took 99% of the CPU and swallowed more than 680MB of RAM, maybe the sources on a shared drive bothered it but I didn’t spend too much time analyzing the problem and quickly proceeded to the next one.
IntelliJ IDEA 6.0.4
The CVS integration worked well for the basic operations of check-ins, check-outs and version comparison, I hadn’t however had the opportunity to try to tagging or merging of branches so I can’t say how it compares to Eclipse’s. Debugging also worked fine, the basics (setting breakpoint, evaluating expressions, hotswap reloading) did just what I expected to do without getting in the way.
And that’s the major decider for me… IDEA simply worked without getting in my way with arbitrary limitations. Where it shines is in the editor, the configurability and the speed at which everything operates: in a “shopping list” of features it might lose to the others, but it wins because the implementation and the design feel more consistent to me.