The State of Java Development on OS X
- Integrated Development Environments
- Text Editors
- Command Line
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
With each new release of OS X, Java development becomes more viable. While it is true that Apple has all but killed the Java-Cocoa bridge, pure Java development on OS X is alive and well. Listed in this article are some of the more common development environments that are being used for Java development on OS X and my current impressions of them.
For the sake of this review, all of the applications discussed were tested on both a brand-new MacBook Pro with a 2.4Ghz Intel Core 2 Duo and a much older Powerbook 1.33Ghz G4. Both of these machines have at least 1GB of memory and a 15-inch screen.
Integrated Development Environments
In this category are the big Java development applications. The criteria for this category are API look-up, internal compiling (via Ant or otherwise), inline error detection, and full project management. Based on that set of criteria, the following applications were reviewed.
Amazingly, none of the three IDEs reviewed here implement some of the features that are considered standard on OS X. For example, soft word wrapping is apparently unheard of in the IDE world. While all of the text editors listed further down in the article support this feature, not a single IDE does. Thus, if you are developing in one of these IDEs, you are forced to an ancient column width restriction that is completely unnecessary. Restrictions of this nature tend to cause other bad habits to form—such as using unmanageably short variable names to try to decrease the width of code.
All three of these IDEs suffer greatly in the usability department on OS X. It is probably because they were all designed for Windows first and then brought over to OS X. If this is the case, it certainly shows.
Eclipse
Eclipse is arguably the most popular IDE for Java in existence today. Because it is open source and free, it is hard to argue against it on the Windows platform. Besides being an IDE, Eclipse is the poster boy for SWT, IBM's Standard Widget Toolkit for Java. As you might know, SWT is a GUI API that utilizes the underlying native widgets instead of drawing new ones in Java code. The theory behind this is that applications using SWT will look more native than JFC applications and perform better as well. While there is a large debate on this statement it is definitely clear that it is not the case on OS X.
The Eclipse developers who are supporting the OS X platform decided to use carbon widgets to implement the SWT on OS X. This was probably done to ease the development as Carbon is closer to other windowing kits on other platforms compared to Cocoa. However, it has been known for years that Carbon's days are numbered. With the release of Leopard, Apple has drawn the line in the sand for Carbon. There is no 64-bit implementation of the Carbon GUI, and therefore it is going to soon be deprecated.
Using the Carbon APIs has another side effect for Eclipse. The UI does not look or feel native on OS X at all. It is very clear that it is a different toolkit and stands out poorly. In addition, it suffers from the same severe usability issues that the other IDEs do, as mentioned above.
However, it does perform quite well. Even on the older Powerbook, it is quite useable. If you can forgive its appearance, it is easily usable as a daily development environment. Eclipse is extremely feature-rich, and if your workflow is in line with the way Eclipse likes, then it is a solid development environment on OS X.
NetBeans
NetBeans is the oldest of the IDEs reviewed in this article. Through its many iterations, it has been hailed as the best and the worst of the IDEs. In its current beta form (6.0 Beta 2), it is a very strong offering in the IDE category. The current layout of the IDE is intuitive and stays out of the way of development. Because it is broken up into a modular design, it is possible to only install the units you need, which is a nice feature.
NetBeans does have some glaring issues, though. As of the current beta, it still does not handle multiple source trees very well. When you are dealing with generated code, test code, and your own source code in separate trees, you have to compile everything, point NetBeans at the compiled code, and then hope that it picks up everything. Otherwise, you will see false compile errors all over the place because it does not look from one source tree to another. It is amazing that this is still an issue.
As far as performance goes, it does run extremely well on the MacBook Pro and performs acceptably on the Powerbook. If NetBeans is your IDE of choice on other platforms, then you will be happy to run it on OS X.
IntelliJ
IntelliJ is the only non-free application in this category. Coming in at $249 for an individual developer and $499 for a company, it is the most expensive application reviewed. With each subsequent release, IntelliJ has added more and more features, and thereby increasing the gap between what it is capable of compared to the two free offerings reviewed. As a Java developer, you would be hard-pressed to find something that this IDE does not do. However, that kitchen-sink mentality comes at a hefty price in performance.
Overall, IntelliJ is incredibly feature-rich, and I used to consider it to be the best of the breed for Java IDEs. However, there are a lot of issues with the latest versions that make it quite frustrating to use on a non-Windows machine. As an example, cvs over ssh is just broken. You can use the internal SSH implementation, but you have to point it to your key files and even then it is not guaranteed to work. As a developer on a UNIX system, there is no excuse for this. Everyone else knows where those keys are and knows to read the ~/.ssh/config file; Idea should also.
As mentioned, performance of IntelliJ is unfortunately lackluster at best. Even on the brand-new MacBook Pro, there were frequent and severe pauses of the application during testing. Monitoring of the CPU, disk access, and memory show that the application is just idle during those freezes and there is no apparent reason for them. As most developers know, this can be an extremely maddening experience while you are trying to bang out a large amount of code. On the older Powerbook, the application was virtually unusable.
It is clear that the developers of this IDE are still focused on two things: Windows and Features. The OS X implementation is slow and bloated. If they put as much effort into tuning the performance of this application as they do in adding features, it would stand head and shoulders above the pack. As it is, this application is too frustrating to use on a daily basis. If IntelliJ is your IDE of choice and you are coming from Windows, you may find it frustratingly slow on OS X. However, because I have not run IntelliJ on Windows in a very long time, it is quite possible that it is slow on that platform as well.