If you want to deliver an application or applet with all the classes and resources it needs - and only the classes and resources it needs, then you need ZipLock.java. The Java Cannery is a similar utility with a different feature set. Here are the doc comments for ZipLock:

This is a utility class for examining a list of class names for all of their dependencies.
ZipLock will read each class file and search the internal structures for all references to outside classes and resources. The checks are recursive, so all classes will be examined. A list of dependencies will be returned.
None of the java.* classes will be examined. Additional system packages may be excluded with setExcludes().
In addition to classes, we look for other resources loaded via Class.getResource() or Class.getResourceAsStream(). If a class calls these methods, then every String constant in the class is checked to see if a file by that name exists on the CLASSPATH in the same directory as the class - in other words where getResource would find it. This heuristic only works if your resource names appear as String constants - which seems to be the case in my practice so far.
We can optionally write all the classes and resources found to a zip or jar, or the list of files can be retrieved with getDependencies().
@author Stuart D. Gathman Copyright (C) 1998 Business Management Systems, Inc.
Original version Copyright (c) 1998 Karl Moss. All Rights Reserved.

When you create a JAR file with all the classes needed for your application, the JAR file is self-contained. It can be run by putting the JAR first in the CLASSPATH and running the main class. It will not break if later version of supporting class libraries introduce incompatibilities. This is similar to the effect of statically linking an executable in a modern dynamically linked OS.

The Object-Oriented jargon for such a self-contained application is a "Sealed System". The original name of this class, "RollCall" just didn't convey this concept. "Sealer" was too boring. We considered "Saran", but "ZipLock" seems more airtight and suggests the underlying ZIP format of JAR files as well!

Keep javac "hot" and ready to roll

A good portion of the time taken by the Sun javac compiler to compile your java code is spent in "startup". The JVM must load and initialize hundreds of classes and resolve references. I have created a simple "compile server" which listens for requests on a socket and invokes the compiler repeatedly. This saves about 10sec for each compile after the first on our 66Mhz AIX system. Here is the source:

Compile.java - the compile server. Run in the background.

Submit.java - a simple program to submit compile requests and display compiler output.

If the reduced startup time for Submit.java is still too much, you can use C++ to submit the requests: javac.cc, socket.cc, socket.h.

A ZIP file with all of the above.

A Formerly Embarrassing Benchmark for AIX Java

This benchmark runs in 6.5 seconds on a 233Mhz Pentium II with MS J++. On a 300Mhz 604 with JDK1.1.4 GA, it takes 16.844 seconds (with JIT). The JIT makes little difference. There is no swapping. Profiling reveals that memory allocation is the bottleneck.

IBM has since released JDK1.1.6 for AIX which cuts the time for this benchmark by more than half by using a per Thread cache for memory allocation and using direct memory references instead of handles. This makes AIX competitive performance-wise with the Microsoft VM - and it's not intentionally incompatible either!

code, soya.att,soya.exs data files
Web page of benchmark author.

Fast Fourier Transform

I have always been fascinated by this algorithm. Here is a Java version adapted from 'C'. It adapts well and there is nothing kludgey here.

FFT4.java

Here is where I got the C code: Jo Desmet, Jo's Web Page

Obtaining JDK1.1.4GA for AIX

IBM no longer has this release on their web site. Several people have asked for it since it is the version they have tested against and need to install at their customers - but they have lost the AIX install image!

You must contact IBM and ask for this release. I am not allowed to redistribute our copy - an IBM lawyer told me so. Very pleasantly and politely, I might add. It is probably easier to retest your applications against the latest release - which is 1.1.6 the last I checked. If this is a problem - then don't lose your install images. Besides, GA1.1.6 for AIX is much faster than GA1.1.4.

You need to register with IBM to gain access to their free developer area.

Elliptic Curve Cryptography

I have translated some public domain C source for Elliptic Curves to Java. I have further changes planned (like interfacing with java.security and making the ECPoint class immutable), but this might save you some work. New - I updated several Java 1.1 anachronisms, and converted the test cases to junit.

The Java source.

The compiled Jar (no manifest yet).

The C source and AIX binary.

You will need junit to run ECTest

GNU Diff for Java

I have translated the GNU Diff algorithm to a Java class. The Diff class computes the differences between two Object arrays as a list of changes. This is very general purpose. Any of the options to GNU diff can be efficiently implemented as variations on how Object.equals() is implemented and how the change list is printed.

DiffPrint now sports a setOutput() method. The DiffPrint.Base class and derivatives should really be renamed out of the empty package.

NOTE - unified and context printing do not combine nearby changes. Perhaps this feature was added since diff-1.15, or perhaps it is a bug. I (or someone) will need to get the latest diff source and add that feature.

Many people have asked me to change the license to LGPL. My port is based on GNU Diff, which is GPL. Until someone convinces me otherwise, I don't believe that I have the right to change the license. I have corresponded with the copyright holders of GNU Diff, and they are unwilling to change the license. Their position is that the GPL helps force companies to GPL more code in order to use existing GPL code.

The GPL restrictions do not apply to purely dynamically loaded code (otherwise, you would be unable to run GNU diff on a proprietary OS). When I get some time, I (or anyone who beats me to it) will create a plugin API so that applications can compile against an LGPL interface, and load the GPL implementation at runtime. This will also make comparing the performance of diff algorithms very convenient. While all Java classes are dynamically loaded at runtime, directly referenced classes are also used at compile time, and thus might be considered in violation of the GPL.

Diff.java The Diff algorithm v1.7

DiffTest.java Test for bugs sumitted by users.

DiffPrint.java A base class for printing the change list in 'ed' style to test the algorithm. Could form the basis for a complete Java implementation of all the GNU diff comparison and output options.

TODO

Publish the revised interface that simplifies doing things with elements that are the same (as opposed to the usual requirement of dealing with just those that are different).

A TimeZone Implementation with Historical Changes and Leapseconds

I have translated the Unix "tz" package (formerly known as "localtime") to a Java class. In addition to reading /etc/zoneinfo files and providing unix like functions such as localtime() and mktime(), it extends java.util.TimeZone providing GregorianCalendar with TimeZones that handle historical changes and leapseconds.

The tz code and zoneinfo files are included with modern Unix systems such as BSD and Linux.

Version 1.11 makes ZoneInfo Serializable.

Version 1.10 uses a better default timezone for zones with erratic changes.

Version 1.8 uses 64 bits for the unix timestamp - which unix systems are going to have to do by 2038 anyway, closes the Zoneinfo file when it is done, and removes the call to Lava Rocks.

ZoneInfo.java

The FTP distribution of the latest tz code and timezone data.

TODO

Zic zoneinfo compiler. Have the compiler detect rational cycles, and extend the zoneinfo file to have a "go back N transitions" feature as suggested by Paul Eggert.

Base64 CharsetProvider

A blatant omission from the Sun API is a base64 encoding (and other encodings like quoted-printable or base85). There are at least 3 private implementations in Sun code for things like javax.mail. There are at least 6 3rd party implementations. Mine is different because it wraps the encodings as a Charset. This is somewhat mind warping because it reverses the usual sense of "encode". To "encode" a byte[] to base64, you "decode" the 8-bit byte[] form to the 16-bit char[] form.

Unfortunately, sun.nio.cs.StreamDecoder is broken, and calls reset() instead of flush() - so that you can't use InputStreamReader with the base64 encoding without losing a char or two at the end.

Base64CharsetProvider.java

JAR File Invoker for JDK 1.1

In Java 2, Jar files are directly invokable with the -jar option. For instance:

$ java -jar myapp.jar arg1 arg2

will look at the MANIFEST attributes for the jar to find the main class, and invoke it. Here is a simple invoker written in Java to provide the same feature with JDK 1.1. It is used like this:

$ java jar myapp.jar arg1 arg2

jar.java The source.

Java Notes

by Stuart D. Gathman Last updated Dec 08, 2010

TODO

TODO

Do NOT send mail to honeybear@editorialunilit.com or pooh@gtsiad.com or pooh@open-mail.org

by Stuart D. Gathman
Last updated Dec 08, 2010