This article is about a small simple collection of batch files which can be used to test the behavior of the javac compiler and java class launcher for different classpath scenarios. The system is called ClasspathTester. Download instructions are included at the end of this article.
When you are in the middle of trying to debug a java build it is a bad time to try to boil everything down to a simple test case, so basically the intent of my test collection is to do this for you ahead of time. If you can’t find the precise test you need, it is easy to modify the existing tests or create a new test to suit your needs.
How ClasspathTester Works
As previously stated, I did everything with batch files, because I wanted the tests to be as uncomplicated, portable (within the Windows environment), and simple as possible. There are a few helper batch files to do things like create formatted output and build a directory structure, but otherwise nearly all of the work is done in the RunAllTests.bat file.
What RunAllTests.bat consists of is tests and sub-tests. If you haven’t downloaded it yet, I suggest you download it and take a look. Each test consists of some sort of a setup. Setup normally involves the following:
1. Test environment is cleaned up of old directories, files, and classpath.
2. New directory structure is created, new files are created and placed in correct directories, and the classpath is set if necessary.
After setup, the tests are run. This consists of running either the javac.exe compiler, the java.exe launcher, or both. That’s all there is to it.
A Simple Example
To understand what ClasspathTester, does, open the RunAllTests.bat file in your text editor and look at TEST1. Each test is a collection of sub-tests which are loosely grouped around some kind of a central testing theme, and TEST1 is one of the simplest.
So what happens in Test1? First it calls banner.bat to add a header to the results file. Then it creates the Hello.java and MyLibClass.java files, by copying them from their corresponding avaj files (the reason for using avaj files is discussed later in this article). Now everything is set up to run some subtests.
TEST1A is very simple. According to its description, ” The Hello.java file is located in the current directory, and the Hello.class file will be written to the current directory and run from the current directory”. As you can imagine, TEST1A operates flawlessly.
TEST1B and TEST1C are designed to show different ways that using java.exe to launch the Hello.class file can fail. In TEST1B the classpath is been set to an empty directory. In TEST1C the file Hello.class is erased. Interestingly, these two tests fail in exactly the same way.
Note that all tests results are stored in the results.log file.
How the Tests are Kept Safe
By “safe” I mean safe to your computer, safe to your other data. Since the tests involve batch files that are creating and destroying files and directories, care must be taken to avoid accidentally destroying or writing over other unrelated files. This is accomplished in the cleanup.bat file by avoiding the use of statements like “erase /S *.*” or “rmdir /S *”. Instead, all erasures are kept fairly specific.
In fact, the cleanup.bat file consists of the following statements:
set classpath=
rmdir /S /Q aq
rmdir /S /Q EmptyDirectory
erase Hello*.java
erase Hello*.class
erase MyLibClass*.java
erase MyLibClass*.class
This ensures that there will be no tragic accidental loss of unrelated data.
Why Use .avaj Suffix Files
Part of the operation of ClasspathTester involves completely wiping the base directory clean of all .java files, .class files, and subdirectories; therefore, all the suffix of all permanent java files is mangled to avaj. For any test, the appropriate avaj files are copied to java files. The available files are:
Hello.avaj
Hello1.avaj
Hello2.avaj
MyLibClass.avaj
MyLibClass1.avaj
MyLibClass2.avaj
Download Information
You can find and download a zipped copy of the ClasspathTester can be on my Article Support Page
Summary
ClasspathTester is simple, portable, unobtrusive, customizable and solves an annoying development problem, the need to quickly test special classpath situations with javac.exe, java.exe, or both.
