The CLASSPATH's effect on JarMaster:

• If you want to update a JAR, you need to ensure that your CLASSPATH points to all the new classes. In addition, the JAR that you want to update should not be explicitly listed in your CLASSPATH. If it is, JarMaster will use the JAR to update itself (which results in an identical JAR that is not truly updated).

  You need to ensure that these two conditions exist because JarMaster uses the CLASSPATH to search for identically named files, which it assumes are newer.

• When building a JAR, if you use classes in the JAVA_HOME/jre/ext and JAVA_HOME/jre/classes directories, you must ensure that these paths are listed in your CLASSPATH. If they are not, JarMaster will report that those classes cannot be found.

  This may seem confusing since you do not need to do this when you compile your applet or application. However, JarMaster relies solely on the CLASSPATH to determine the location of all required classes when building JARs. So, even if you can compile without these paths in your CLASSPATH, you will need to include them when building a JAR with JarMaster.

• If you want to include the JDK core classes, and have removed them from the exclusion list when building a JAR, they will still be missing from the final JAR if they are not listed in the CLASSPATH. (The exclusion list appears when you use the JAR building Wizard and when you add new dependencies).

  JarMaster uses your CLASSPATH to search for desired classes (in this case, the JDK core classes), so you must ensure that the CLASSPATH includes these core classes. These are found in JAVA_HOME/jre/lib/rt.jar.

• If you want to add new files or add new dependencies to a JAR, the CLASSPATH must point to the desired files; otherwise, JarMaster will not be able to find them.

• It is a good practice to compile your app/lib with your current CLASSPATH setting before running JarMaster. Generally, a successful compile verifies that your CLASSPATH is properly defined for this particular app/lib.

• Remember that JarMaster does not automatically save changes when you make them to a JAR. If you attempt to close a modified and unsaved JAR, JarMaster will prompt you to save it.

• When you add files or copy files to a JAR, the information for the new files does not include file size, compression ratio, or compressed file size; these fields are blank. You must save the JAR to update this information.

  When adding or copying files to a JAR, they are only visually added in the interface. Once you save, they are physically added to the JAR, and all file information is updated.

• It is possible that when you make changes and then save a JAR, none of the changes are retained. You will notice this if you reopen it and find that it looks like the JAR before changes were made. This happens if there was a problem in saving the JAR with the file name chosen, possibly because of write permission conflicts.

  To recover the new JAR, you can copy the temp.jar file found in JCLASS_HOME/lib. This temporary JAR is the most recent JAR worked on in JarMaster, and is retained even after JarMaster has been closed.

• The evaluation copy of JarMaster is limited to 200 entries when saving a JAR file.

• If you are creating or editing manifest entries, and have tags that are not directly supported by the manifest editor, you can still include them. The manifest editor has an area that allows you to enter unsupported tags; anything you enter in the text area is appended to the manifest entry.

  For example, suppose there is a new tag called "Foo:". You can add it to the manifest entry by typing the following in the text area:

  Foo: value

  This will be appended to your manifest file exactly as it is seen in the unsupported tags text box.

• If you want your JAR to include dynamic dependencies or non-class files (for example, Class.forName("package.MyClass")), you will find that they are not included when the JAR is built. This is because JarMaster has access only to CLASS files. Dynamic classes are seen as String objects until the applet or application is executing.

  In order for them to be included they must be manually added to the JAR, or better yet, specified in the manifest file. For example, MyClass.class has a line of code that contains a dynamic class:

  Class c = Class.forName("package.MyClass2");

  In order for JarMaster to find MyClass2.class, your manifest files must have the following entry:

  Name: package/MyClass.class
Depends-On: package/MyClass2.class