I did a few more tests to try to determine how the UCDJ program determines where it writes temporary files for RA solutions. Here is what I learned.
Working directory set with CD | Working directory set with user.dir | UCDJ writes RA solution temporary UI files to
| UCDJ writes RA solution temporary help files to |
UCDJ bin directory | UCDJ bin directory | ..\temp\RA | %USERPROFILE%\.RA_Help |
%USERPROFILE%\AppData\Roaming\UC4 | %USERPROFILE%\AppData\Roaming\UC4 | %USERPROFILE%\.RA | %USERPROFILE%\.RA_Help |
%TEMP%\UC4 | %TEMP%\UC4 | %USERPROFILE%\.RA | %USERPROFILE%\.RA_Help |
C:\UC4 | C:\UC4 | %USERPROFILE%\.RA | %USERPROFILE%\.RA_Help |
UI windows related to RA solutions (e.g., RA agent & job windows) have their own solution-specific tabs. Each RA solution is different, so these require additional code to be loaded before they can be displayed. (This explains why it can take some time to display an RA agent or RA job window the first time.) This code is downloaded from the Automation Engine, and cached locally in temporary UI JAR files on the machine where UCDJ is run. Once the UI JAR files for a particular RA solution have been cached, the UI is clever enough to know not to download them again.
UI tabs related to an RA solution also have a
Help button. The first time this help button is clicked for a particular RA solution, a JAR file containing the help files is downloaded. UCDJ always writes these help JAR files to
%USERPROFILE%\.RA_Help
,
regardless of the current working directory. The names of these files are generated dynamically. The first RA solution help JAR file downloaded will be named
help0.jar, the second one,
help1.jar, and so on.
Now, my hunch about the root of the problem...
Different part of the UCDJ program appear to determine the
current working directory differently. Some parts appear to pick it up from the directory set using
CD, while other parts of the program appear to determine it from the
user.dir system property. It seems likely that the problem I found arises from this inconsistent way of determining the current working directory, combined with the invalid assumption that the two will always be the same. When the working directory set via
user.dir is the
UCDJ bin directory, but the working directory set via
CD is another directory, my guess is that program performs one action using one of these directories, and then tries to perform a second action using the other directory. If for example, the program is writing the file in step 1 and then reading it in step 2, then if the directories used in the two steps differ, this could cause the problem.
It would obviously be preferable if UCDJ were consistent in the way it determined the current working directory, throughout the program. And again, it might be better to determine the proper location for writing temporary files by reading the
java.io.tmpdir system property.