These changes are the less critical parts of CR 6657688 that didn't get put back in time for build 13. It includes at least:
  1) Factoring the conditionally compiled unit test main methods out to separate source
     files.
  2) Updating unit test scripts for (1).
  3) Eliminating default defines of DEBUG. Note that with 6657688 the body of LogFprintf
     was made empty for compiles done during builds, making the code conditionally compiled
     with DEBUG effectively null operations.
For the sake of diagnosing future problems with jbroker related to per-dir and per-file
security checks, it would probably be useful to change the above DEBUG-conditioned code to code keyed off a "verbose" flag that can be enabled with a registry key  (not a command line option, as support staff and/or users cannot ordinarily insinuate the option into jbroker's normal startup during an install. In this case LogFprintf should be changed to send "fatal error" information with standard deployment routine "logit" and each fatal error msg sent to the log should include enough details to determine the specific file/dir/bundle involved with the error. This alternative to either "standard stream output" or an error "message box" is required because the former simply doesn't work for the kind of Windows app jbroker is and the latter violates UI specs with information that end users can't use,

EXCEPT that it would be nice for an RFE to ammend the UI spec to accomodate a special case that is unavoidable and has no real workaround because of Windows OS semantics. This involves the case where a jbroker "secure move" operation is stymied by Windows error 32 (ERROR_SHARING_VIOLATION "The process cannot access the
file because it is being used by another process"). In this case a carefully worded message box could be very useful to inform a user that an install cannot be completed until conflicting use of a (exactly specified) directory or file is completed. In plain words, it means "your computer is trying to both use and install at the same time, or it is running a program running in an install-related folder that prevents installation from completing." The current Java Kernel architecture supports automatic recovery if for this special case a user got the chance to wait for the conflict to go away (e.g. a disk backup operation), or to take action to correct it (e.g. cd back out of "Sun's special transient folders"). Also, this illustrates an issue that extends beyond jbroker (e.g. the online installer .exe file has similar issues with error 32).