[Clockwork-developers] Java, anyone?

[Joel L. <jo...@lo...>]

I've been kicking around some ideas about the language to use to write
Clockwork, and while I was resistant at first, I think Java might work well.

Java would take care of much of the portability for us (remember that we
stated in the requirements that Clockwork needs to run on Windows, too). It's
also made easy the tasks of memory management, data structures, network
communication, threading, and even logging (Jakarta's log4j is quite good).
It really seems like Java would let us spend more time writing code that
actually runs the scheduler, without having to stop and first create a
message-passing system, a generalized logging system, and other low-level
stuff.

One of the drawbacks of Java is that you can't really depend on a version
of the JRE to be installed on a target system. But we could simply package
the software with an acceptable JRE for each platform (which is what
commercial vendors do with Java and with Perl). It would even be possible
to make a version of the software that comes without a JRE for folks who
don't want another one.

And there's the foolishness with $CLASSPATH and the fact that Java programs
don't look quite like other programs in 'ps' when they run, but we could
easily wrap them with shell scripts to make startup and shutdown easier.

I really think that if a user is able to pkgadd/apt-get/rpm/swinstall our
software package, edit a couple of configuration files, run
'/etc/init.d/clockwork start' and get the software running, then it doesn't
matter if it's Java and we had to bundle it with a JRE. If install and
setup is easy, users will use it. LimeWire is a great example of this. It
can install its own JRE if you want, and it's almost transparent. You just
run an installer and it works.

The Berkeley DB code has a Java interface, but it uses native code as the
backend. So we'd need to have separate software packages for each platform
for that reason. But I don't think this is a really big deal. Rather than
doing like RedHat's RPM and assume that db >= version _x_ is installed and
in your $LD_LIBRARY_PATH, which forever ties together your db and rpm
software, I'd rather just stick the db libraries for whatever version we've
tested with in a lib/ directory along with the rest of our software.

-- 
Joel