• Why a command-line utility?
• Why Java?
• Why are you forcing me to use a 1.5 JDK?
• FreeBSD's 1.5 JDK blows up when it runs curn
• What scripting languages can I use to write a script output handler?
• Can I write a perl script output handler?
• I've written a Java output handler (or RSS parser adapter). Why won't curn find it, even when I put its jar file in my CLASSPATH?
• I've written a plug-in. How do I install it?
• I think I found a bug. What do I do?
• Why doesn't your code follow the standard Java coding conventions?

Why a command-line utility?

I wanted something that was simpler than the existing graphical RSS readers, something that could run unattended and notify me periodically, but unobtrusively, when new items were posted to RSS sites of interest. For me, email is a good notification mechanism. curn sends me email every so often, with updated information from a configured set of RSS feeds; the resulting snapshot information sits unchanged in my mailbox until I'm ready to read it.

Why Java?

A few reasons.

• At the time I wrote curn, I'd been using Java professionally for a long time. I was comfortable with it (still am) and was familiar with the various Java tools for handling XML, generating HTML, etc.
• Java is portable. For this kind of application, "Write Once, Run a Lot of Places" is an easily realized goal.
• curn was a good application to help shake out my Java utility library. It's also a good testbed for experimenting with various Java APIs.
• I can live with the slight performance hit associated with interpreted byte-code. curn spends most of its time doing network I/O; using a native compiled language wouldn't improve its performance dramatically enough to be worth having to compile it individually for every supported platform. Plus, I typically run it in the background, via cron(8), so I don't notice that it's a little slower than, say, a native C application would be.

Of course, now that I've done a fair amount of work in and become a real fan of Python, the above reasons also apply to that language. If I were writing curn all over again, I would probably choose Python. (Or maybe not. If I were going to rewrite curn in Python, I'd probably just use rawdog, which is already a lot like curn but written in Python.)

Why are you forcing me to use a 1.5 JDK?

For some time, I stuck with the 1.3 JDK, refusing to use even 1.4-specific features. But I finally standardized on Java 1.4, and then on 1.5, for the following reasons:

• There are various features in 1.5 (generics, the for each construct, enums, etc.), that I want to be able to use or experiment with.
• I wanted to be able to use the assertion facility that was added in the 1.4 JDK.
• The regular expression classes that come with 1.4 are more extensible than the Jakarta ORO classes I was using; they work with anything that implements the CharSequence interface, not just with String objects. Plus, using java.util.regexp, instead of Jakarta ORO, removes a third-party library dependency.
• There are some useful new classes and packages in the 1.4 and 1.5 JDKs (e.g., java.nio.*, new java.util classes, java.util.concurrent, built-in regular expression support, a Preferences API that I might decide to support in curn, etc.).
• Even FreeBSD, my platform of choice, has a 1.5 JDK these days. FreeBSD tends to lag behind under platforms in JDK support (due to a lack of official support from Sun). However, FreeBSD does have 1.4 and 1.5 JDKs, so it's reasonable to assume that those JDKs are available for other, more popular, platforms.

FreeBSD's 1.5 JDK blows up when it runs curn

There is a known problem with older FreeBSD 1.5 JDK thread handling. Under certain conditions, the Java VM will dump core when multiple threads are running. curn can reliably trigger this bug, when it is configured to use multiple download thread. To avoid this problem, simply configure curn to use only one download thread, by setting its MaxThreads configuration parameter to "1". This problem does not occur with a Linux or Windows 1.5 Java runtime.

What scripting languages can I use to write a script output handler?

The short answer: Any scripting language for which an Apache Jakarta Bean Shell Framework (BSF) scripting engine exists. Alternatively, if you're using a Java 6 VM, you can also use the javax.script API; there are prebuilt scripting adapters for that API available at https://scripting.dev.java.net/. For a longer answer, see the section in the curn User's Guide that describes how to configure an instance of the ScriptOutputHandler output handler.

Can I write a perl script output handler?

No. There is a BSF scripting language engine that purports to work with perl scripts. It's located at http://bsfperl.sourceforge.net/. It's very alpha. Among other things, it doesn't appear to support putting arbitrary Java types into the BSF framework. (Its mapper class, net.sourceforge.bsfperl.PerlPrinter, supports a limited number of Java-to-Perl type translations.) This restriction makes it unsuitable for use with curn. However, maybe that'll change over time.

I've written a Java output handler (or RSS parser adapter). Why won't curn find it, even when I put its jar file in my CLASSPATH?

As of version 3.0, curn uses its own custom class loader which ignores the CLASSPATH setting. (I may change that in a future release.) The custom class loader is necessary to support plug-ins. The easiest way to install your custom output handler (or parser adapter) is to copy its jar file into one of three places:

• ${curn.home}/lib
• ${user.home}/curn/lib
• ${user.home}/.curn/lib

${curn.home} refers to the curn installation directory. ${user.home} is the home directory of the user running curn.

See the Installing Supporting Software, Writing Your Own Output Handler, and Using an Unsupported RSS Parser sections in the curn User's Guide for more details.

I've written a plug-in. How do I install it?

Pack the plug-in class(es) in a jar file, and copy the jar file to one of these directories:

• ${curn.home}/plugins
• ${user.home}/curn/plugins
• ${user.home}/.curn/plugins

${curn.home} refers to the curn installation directory. ${user.home} is the home directory of the user running curn.

For more information, see the Installing Plug-ins and Overview of Plug-In Support sections in the curn User's Guide.

I think I found a bug. What do I do?

I need as much information as possible to diagnose and reproduce the bug. So, please run curn with logging enabled, and mail me the log file. See the Logging section in the curn User's Guide for details on how to enable logging.

Why doesn't your code follow the standard Java coding conventions?

Because I don't like them. Seriously, though, you're probably referring to my curly brace style, which is definitely at odds with the recommended Java style (which, in turns, borrows from one of the more popular C language coding styles). Put simply, I like white space. Putting braces on their own lines (as opposed to on the same lines as other code) leads to more readable code. In my opinion of course. You're free to differ--in your own code.