java.library.path fix for MacOS X (7145798)

[Mike Swingler]

On Feb 20, 2012, at 9:20 AM, Greg Brown wrote:

>> I think the JavaVM really lives inside of the *.jre or *.jdk bundle inside Contents/PlugIns, and the contents of the directory in question is really Java parts of the "app" and does not contain aVM. The contents of the Info.plist dictionary key is the description of the application to the launcher code, and indirectly to the JavaVM.
>> 
>> I believe that overloading the same name for both the directory and the Info.plist key is a mistake.
> 
> I buy the argument that the JavaVM directory does not contain a Java VM and therefore should not be called "JavaVM". However, I'm not sure why using the same name for the directory and the key might be a mistake. Isn't that how it was done in previous versions, using "Java" instead of "JavaVM"?

Yes, and I full acknowledge that it was a mistake. The Contents/Resources/Java positioning was the biggest mistake of all (in hindsight of code signing, which came later). The "Java" key in the Info.plist was too generic, and didn't follow the sub-system prefix convention of other Info.plist keys (CFBundleVersion, LSUIElement, etc). That is why I choose "JVMInfo" ("JVM" prefix), but now that I'm really thinking about it "JVMAppInfo" or "JVMApp" might be more appropriate. I'm completely open to suggestions.

The name of the directory is less important, as long as it accurately conveys the content of what is inside. All of the contents of the directory are hauled onto the classpath, perhaps "ClassPath" makes sense, if there is no intention to manually specify the classpath with app-reletive paths from the Info.plist.

> I think you said that the directory name is not relevant to the Launch Services code - if so, maybe it would be best to use "JavaVM" as the plist key and "Java" as the directory name?

I think that makes sense.

Regards,
Mike Swingler
Apple Inc.