Java text editing software for Linux

When I ran into Slava Pestov, the core developer of Jedit, on IRC, I asked him what he thought of some of the increasingly popular Java-based integrated development environments (IDE) such as Eclipse and NetBeans. To paraphrase his opinion, IDEs are just bloated editors loaded down with a bunch of wizards. I might agree — with the possible exception of Eclipse, which isn’t editor-centric. Where Slava and I probably differ is that I like both; there are times when I want a lean, mean editor and times when I enjoy a good, bloated editor packed with wizards.

Fortunately, there are plenty of both to go around for the Linux user looking for a Java-based development environment. In my last article, I raved about one such program, called Jedit. Jedit alone is a lean, fast editor. Nevertheless, so many excellent plug-ins are available for it that one cannot help but be tempted to use them. As a result, a fully loaded Jedit actually begins to rival full-featured IDEs — bloat, wizards and all. Here’s a rundown of the memory usage of Jedit without plug-ins as compared to two similar editors, J and Jext.

Once I added all the plug-ins I wanted, Jedit’s memory usage nearly doubled. That’s not so bad when you consider that I have a whopping 34 plug-ins loaded (there are many more available, which I chose not to install).

Meet editor No. 1: J

The J editor manages to deliver many of the features in Jedit without plug-ins and without consuming as much memory. One reason is that J reeks with just enough geek to be efficient and just enough pizazz to be appealing. If you’ve been using console-based editors, you’ll feel right at home. It also includes enough convenience to prevent most people from tossing it out the window on the first try.

Here’s its secret: J treats just about everything as an edit buffer, including help files and directory listings. The left-hand pane contains a folder tree, much like the Windows Explorer. When you click on a folder, a list of files in that directory appears in an editor window. On first glance, it almost looks like this action is useless, as the editor window appears to be a text file with a listing of your directory. However, if you double-click on a directory in that file, you’ll navigate the same way as if you used the folder tree. In addition, if you double-click on a file, it will bring up that file in the edit buffer.

Editor’s note: The above image is reduced in size to allow it to display on this page. Click on this image to see the original.

Keep this in mind when I tell you that there’s no fancy configuration dialog in J. You’ll have to edit a configuration file if you want to tweak it to your liking. That’s not necessarily a bad thing, unless you’re a Windows programmer who needs a dialog box for everything you do. The rest of us can handle the average configuration file without complaining, as long as it’s done right. J does it right. If you want to customize J, simply press F1. J will open up another buffer window and display the help file, this time with hypertext links. Click on the “preferences” link and the help screen takes you to a description of the file you’ll have to create or edit to configure J. Open up another buffer for that configuration file to view the instructions to customize J in one window as you edit the configuration file in another. While I may prefer the convenience of the Jedit configuration dialog, I had J customized to my liking in just a few minutes.

Although J may not have the reservoir of plug-ins you can find for Jedit, it still boasts an impressive set of built-in features. It does all of the basics I require from a programmer’s editor. It features syntax highlighting, it automatically highlights matching braces and automatic indents, and it has the basic buffer- and block-handling. It even has a very quick source-code beautifier, a feature neat freaks will appreciate. Technically, J is extensible through plug-ins, but there is no user-friendly interface for installing them, and I could not find any premade plug-ins to install manually.

I encountered one very pleasant surprise when I loaded a PHP program into J. It automatically extracted and listed all of the function names in my PHP program in a docked panel on the left. I could jump to any one of those functions by clicking on the function name in the list. A plug-in provides this feature in Jedit for Java source code, but I haven’t found a way to make Jedit do this with PHP files. I suspect I can make Jedit honor PHP function names by using a utility called ctags, but I’m impressed that J provides the feature without any effort on my part.

You can view graphics files directly within J, and last but not least, J includes (of all things) an e-mail client. While there’s no preconfigured way to compile and run the source code you’re working on, you can take comfort in the fact that if you suddenly have the urge to check your POP3 or IMAP e-mail account, you can do it from within J.

Meet editor No. 2: Jext

Jext falls somewhere between J and Jedit in terms of ease of use, speed and extensibility. It supports plug-ins but doesn’t expect you to hunt for them. All of the useful plug-ins I could find are shipped with the editor and installed by default.

It has a nice docked panel on the left for navigating through project files, bookmarks and text searches. There is also an Xinsert panel, which is a hierarchy of canned text and functions. For example, if you click on “Check browser” in the JavaScript branch of the tree, it will insert into your current buffer all the JavaScript code necessary for browser detection. There are a wide range of canned functions, scripts, keywords and other ways of automating the coding process available for various languages. If you are editing a PHP file, Jext automatically presents the Xinsert options most often used in PHP. However, it doesn’t prevent you from switching modes if for some reason you can benefit from using Xinsert to stuff some Java code into your PHP file.

Editor’s note: The above image is reduced in size to allow it to display on this page. Click on this image to see the original.

Jedit has a plug-in that provides this Xinsert feature, but, as far as I can tell, the feature is unavailable for J.

Jext lets you write Python scripts and execute them directly from the edit buffer, which makes Jext one of the more powerful Python editors around. Jext also includes the ability to write Dawn scripts and execute them directly from the editor. Dawn is the internal scripting language for Jext. By comparison, Jedit also has a plug-in that provides a Jython interpreter (a way you can write Python source code and execute it as Java byte code). Jedit has to load Jython separately, however, and it runs the Jython interpreter in a window separate from the normal edit-buffers.

The other notable features of Jext include a built-in console and a way to record and play back keystrokes (there’s no formal macro manager, but remember that you can always write Dawn scripts). And although I prefer the Jedit file picker, the Jext one is still quite nice.

My biggest complaint with Jext is that it remains unpolished in several areas. The installation was crude. If you download the right file, the first part of the installation uses a graphical interface, which is nice. However, when you try to run the program for the first time, it executes a barely usable shell script. If you misunderstand one of the prompts, the script crashes but leaves Jext running in the background. Finally, it complains that your mouse won’t work the first time you run Jext, but if you tell it not to disable the mouse wheel, you’ll see that it actually works fine.

Fantastic fonts

There’s one last aspect of editors that too often is overlooked. I might be willing to spend eight hours a day staring at an out-of-focus picture of Shania Twain, but somehow Java code simply doesn’t provide the same incentive. I settle for nothing less than good, clear fonts in a programming editor. I prefer anti-aliased fonts, but they are not necessary. All three editors — Jedit, J and Jext — include options to anti-alias fonts. In theory, I would have expected all three to anti-alias fonts with identical quality since the Java virtual machine should be doing the work. For a reason I don’t understand, however, Jedit seems to render the text best, while J does anti-aliasing the fastest.

The cost in performance with J is hardly noticeable. Anti-aliasing has a much bigger impact on the performance of Jedit, at least on my system. It’s not enough to eschew anti-aliasing altogether, but it was enough of a performance hit to make me experiment with font types and sizes that would run better with anti-aliasing turned on.

Whether or not it would slow down the performance of Jext seems to be academic, because I couldn’t make it work. The version I tested has a font-anti-aliasing option in its configuration dialog, but it’s grayed out. I tried setting it manually by editing the configuration file, but that didn’t help.

Editor’s note: The above image is reduced in size to allow it to display on this page. Click on this image to see the original.

Fortunately, the Verdana font looks fine in Jext without anti-aliasing, so that’s what I use. If you end up liking any of these editors and want to avoid anti-aliased fonts, I suggest you experiment with the fonts you have available on your system, since your mileage may vary in terms of quality. The readability of any given font depends on a combination of the version of XFree86 you are using, your XFree86 font settings, your current screen resolution, the “dpi” setting (dots per inch), the video card you have installed and the font server (if you are using one).

The verdict

Jedit is still my favorite programmer’s editor, so I recommend you look at it first. If it’s too much editor for you, or if you don’t want to deal with the plug-ins but still want to give a Java-based editor a chance, then I recommend you try both J and Jext. If you are at least part geek and want the leanest, fastest editor, then I predict you’ll fast become attached to J. If you’re almost sold on Jedit but want something a little less frilly, then Jext will probably be the editor for you.

Reader tips on Linux usage

A LinuxWorld reader recommended using the IBM JDK 1.4 instead of the one from Sun or Blackdown. I had some problems with older IBM JDKs on Linux, but I gave it a shot. Unfortunately, even the latest IBM JDK still presents problems when running some of these client programs, probably because the IBM JDK is optimized for server use. The most noticeable problem was that some of the configuration screens in Jext don’t show up at all when I use IBM’s JDK. The IBM JDK also seems to be slower for client programs. Unless I discover that some other portion of my Linux installation is at fault (such as the glibc library), I cannot recommend the IBM JDK for use with these editors.

Another reader pointed out that you can get Java Webstart from the Sun Microsystems Inc. JDK now. I downloaded the j2sdk1.4.1_01 package from Sun (I was running 1.4.1) and sure enough, it was there. Although Blackdown often has an edge on Sun when it comes to Java implementations on Linux, Sun probably has the latest and greatest as I write these words in late January 2003.

Here’s another gotcha you might run into. Linux users love their virtual desktops, and I am no exception. I was perturbed at one point to find that Jedit suddenly stopped using the KDE window title bar and instead displayed the default Java Swing window title bar. The Swing window title bar looks fine, but it prevents me from using several KDE features, such as the one that lets me move the editor from one virtual desktop to another. It was obvious that a Jedit plugin switched a setting somewhere and didn’t switch it back after I had uninstalled the plugin, but I had no idea which setting it was.

Java programmers will probably know the answer to this problem immediately, but I had to give myself a quick refresher course in Java graphical user interface (GUI) programming to figure it out. Java Version 1.4 introduced the ability to turn off decorated window frames, which allows your Window manager to handle the top-level window frame. If you run any Java GUI-based client programs, look for an option in your configuration dialog or configuration file that lets you turn off decorated frames. This should bring back your window manager’s default title bar.

I hope to tackle at least one of the many bloated IDEs in my next article. Until then, happy editing, courtesy of Java.

Nicholas Petreley is a computer consultant and author in Asheville, N.C. He can be reached at nicholas.petreley@linuxworld.com.