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

[Greg Brown]

>> 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.

I see. I don't really like "JVMAppInfo" or "JVMApp" - I think that "app" is sort of implied by the fact that we're in an app bundle. I liked "JavaVM" because I think it accurately represents the contents of the dictionary - information that we use to initialize the JavaVM at startup.

Is there a document that describes the recommended naming conventions for application-specific plist keys? I'm not opposed to using a prefix, but I'd like to understand just how much of a break from convention "JavaVM" would be before making a change.

> 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.

Great. I'll update the bundler task and launcher code to use "Java" instead.

Greg