To support the project we will need tools like:

CVS (supports concurrent code development),
Bonsai (a CVS monitoring system),
LXR or HyperJava (hyperlinked code browsers),
Tinderbox (a build watcher),
JIndent (a Java source code pretty printer),
JavaDoc or Polardoc (generates html marked up java comments),
JavaCC or BYACCJava (java compiler-compilers),
JGL (implements many common algorithms and advanced objects),
javap or Mocha or WingDis (disassemblers),
OROMatcher (a Perl5 regular expression matcher),
a profiler (in addition to "java -prof"),
javaprof (a profile pretty printer),
ProfileViewer (a graphical profiler),
Avalanche (an encrypter),
a Java parser,
a thread manager,
assertion tools, and
an optimizer.

See mozilla.org's open-source software tools page, the Imperial College, UK, Java development tools ftp site, Java utilities ftp site, and Java general tools ftp site. Also, see the Sun's java site, and the Gamelan, Gnu, Linux, and Perl sites for yet more links. The following site seems to have a lot of links to open-source support tools.

Here's an amusing page describing what a Java pretty printer should do and why one didn't exist then. The only Java pretty printer I know of is JIndent, but it is not yet up to snuff. See WebView for a first stab at an animated website mapper written in Java. This is also food for thought for our project in general. See the Jazilla site for an example of a large, visual, portable Java project using some of the same tools (they're building a Java browser).

A previous term's networks team has already installed a hyperlinked news server, a web chat server, a smart mail server, and a website searcher. We now need better versions of all those programs and we need a web annotator and a web whiteboard. These tools, and others like them, are very important to the proper functioning of the seminar and the resulting project.

Wherever possible we should use preexisting tools unless they require a commercial license. If no appropriate tool exists we have to develop our own open-source version. All the code this project needs to run must eventually be fully open-source and cross-platform, so although we might use programs like, say, make and Polardoc, in initial development, we cannot use either of them in final production because make is unix-specific and Polardoc is going commercial.

Of course, some tools, like Apache and HotJava, are simply too big for us to write or rewrite ourselves. Integrating fully portable versions of those kinds of tools into the project will have to wait until hardy and strong-willed outside programmers get interested.