This is a utility class for examining a list of class names for all of their dependencies.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.
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
In addition to classes, we look for other resources loaded via
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
getResourcewould 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
@author Stuart D. Gathman Copyright (C) 1998 Business Management Systems, Inc.
Original version Copyright (c) 1998 Karl Moss. All Rights Reserved.
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!
A ZIP file with all of the above.
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!
soya.att,soya.exs data files
Web page of benchmark author.
Here is where I got the C code: Jo Desmet, Jo's Web Page
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.
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.
/etc/zoneinfo files and providing unix like functions
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.
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.
$ java -jar myapp.jar arg1 arg2will 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