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.
NB user and community member here.
>* 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)
In the dialog which comes up for encapsulating you can change the generated method names. I take it you mean it should recognize m_ in front of the variable name? p_ would not make much sense really though you wouldn‘t be using encapsulation for these. I could see m_ in this context though. I‘m not sure what other styles there are though. It would have to be configurable.
Just a personal note: A long time ago I used to use m_ for module variables (class level variables). Now days I find it makes the code easier to use and read by simply using this in a context where they collide. I found if the code was broken up, made more sense, and was readable I always knew the context anyways. So, I never distinguish between the two any more other than using this where I have to and only where I have to. For the editor if you need you could simply register t_ to expand to this. Then t_ would expand to “this.”
FYI there is also a separate module for adding many many many more refactoring features. You can even create rules files for it to do an entire refactoring of your project or write Java and use its API for more complicated stuff for a huge refactor or simply very complicated concepts.
>* 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
Yes, working on files over a shared drive like this do not work well in NB. I can see how some might do this, but I never do development on shared drives and the like because it can get you in a JAM.
1) if you ever have to move your computer to a location where this drive doesn‘t exist you have to find a new shared drive or reorganize to a local drive. I use backups at the end of the day using tools like ActiveSync which can synchronize my files. So, once you sync first you don‘t ever worry about a full copy of all files. I have a process for a high-speed external drive and for my companies VPN to a shared drive. You could have a private repo on your company CVS server for this stuff to which would be backed up by company processes.
2) If you are editing a file and something happens to your network link. You end up having to save it off to some where else. If you edit more than one file and haven‘t been saving often you can end up with multiple files. Which is fine, but I just don‘t like risks like this in that what if the IDE (any IDE including my C++ and VB ones) were to crash in the mean time. I‘m a save button freak though. I have been bitten by different configurations in the past.
>* the JSP code assistance produced weird code, for example I typed
> and then Enter, and it
>added a that makes no sense
Sounds like a bug you might file at:
it will help those of use using NB. It would be a big help if you did this while using NB. We will all thank you for it :-).
>*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
That would be a cool feature to have. Context aware JavaDocs.
>*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)
I haven‘t had too much problem here. I sometimes have issues if I forget compile in debug symbols, but this should be the default for NB projects I believe. Not sure about JSP pre-compiled classes though if these are the ones you are having issues with. Maybe you could file some more bugs? It would really be a big help.
>*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
I have never seen this one. I use NB all the time and have it up through many hibernates of Windows XP. I might restart it every couple weeks even when using it daily. Sounds like some type of an issue with a memory leak some where in the JRE or JDK, but could be in NB. This would be good if you could file too and attach your log file.
I have to agree with you. Since I‘ve used Intellij Idea I never managed to go back to Eclipse. I‘ve tried Netbeans though. The 5.5 is quite good and integrates well with Glassfish. I followed some of their tutorial, like the one creating a CRUD application using JPA and JSF from an existing database. That was quite impressive and I can see the benefit of such a feature when creating basic administration CRUD pages.
But other than that, I‘m still a Idea follower (I‘ll give Netbeans 6 a try though).
For the JDeveloper part:
>>I couldn‘t find an option to open JSPs by default in the source editor rather than in the visual editor
All you had to do is ask this on the JDeveloper discussion forum (or do a search there) and you would have found that you can use the tools->preferences->File Types and set a default editor for each file type.
I was quite interested to see this post, as I am an IntelliJ fan, and would like to encourage my team to move across. Unfortunately I cannot recommend this post, as the bias seems to be that you are someone who has used IntelliJ in the past, and was looking for something better. Not someone who had used Eclipse and was looking for something better.
It looks to me you gave up on Eclipse too easily. The bug issue you linked to describes a workaround that seems perfectly fine to solve your problem, and with Eclipse would not have all editor hassles you had with NetBeans, besides having better performance and using less memory than with NetBeans and JDeveloper.
That‘s a pitty because your evaluation of NetBeans looks very unbiased to me — and I do use NetBeans on a daily basis. For my needs, there are features like Matisse that weights more than the editor and peformance problems.
I also work with Eclipse almost as much as with NetBeans. Different projects have different needs.