Are Windows Logo (TM) Certified applications harder to write in Java?

Question

Third party vendors using our software as a component view Windows Logo Certification as an important selection criteria. 90% of the requirements are easy to adhere to given the flexibility in deploying Java programs. Some immediate difficulties present themselves:

• Tagging jar files with resource strings for versioning information.
• Moving From properties files to .INI files
• Short Path Name / Long Path Name / UNC isn't well support by the libraries
• Look and feel requirements

These will require some serious recoding to address. I may be interpreting the specifications too closely. I found one decent example of an application that obtained Windows 2000 certification. The look and feel in this instance only refers to any visible installer that we present. Even the specifications themselves imply things in the descriptions that are not really covered in the title of the requirement.

1.5 The application should not read from or write to Win.ini, System.ini, Autoexec.bat or Config.sys

excerpt:

If your application uses information that you do not want to put in the registry, create a private initialization file and place it in the directory with the application's executable files. You can easily manage the installation of a private .ini file, as well as add or remove information from existing .ini files, by using Windows Installer to install your application.

Any feedback would be appreciated.

Answer 1

For the look and feel, call this at the beggining of your main() function:

    log.info("Setting java look and feel");
    try {
        UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
    } catch (Exception e) {
        log.warn("Could not set system look and feel", e);
    }
    // Make sure we have nice window decorations.
    JFrame.setDefaultLookAndFeelDecorated(true);
    JDialog.setDefaultLookAndFeelDecorated(true);

Answer 2

Please note that the example of an INI file should not be taken as a mandate. What you call the "title" is really the requirement itself. The reason for this is that the specifications are intended (amongst others) to prevent application installations from interfering with each other. Moving to private configurations (whether in the file system or in the registry) supports this.

In fact, the current suggestion is no longer INI files, but the registry for small parts of the configuration, and XML files in %APPDATA% if you've got a lot.