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

[Mike Swingler]

On Feb 20, 2012, at 11:02 AM, Greg Brown wrote:

>> I don't believe there is a way to augment the human readable mappings in the plist editor.
> 
> That might be a good reason not to use prefixes in app-specific keys. Not sure, just thinking out loud.

This is an interesting case, because you are straddling the line between "3rd party app" and "framework provider".

Do you anticipate that developers will want to manually edit the plist after it's been created?

> The reason I ask is that I'm wondering if we should just flatten the "JavaVM"/"JVMInfo"/"whatever" dictionary and use prefixes on the nested keys:
> 
> JVMRuntime
> JVMMainClassName
> JVMOptions
> JVMArguments
> 
> Seems more consistent with Apple's current convention. I was thinking that it would be nice if there was a way to present these using localized, human-readable names in the editor. But it doesn't sound like there is - oh well.

Flattening the prefixed keys to the top-level seems reasonable, and more in-line with existing convention. It's a good idea.

On separate topics:

* Do you plan to do any macro expansion on the JVMOptions or JVMArguments?

I like the automatic inclusion of all .jars in the Contents/Java directory onto the classpath, and might even suggest recursively scanning the directory. Though, some developers will want to make additions to it (the example of adding tools.jar to the classpath just came up), which sort of re-opens the flat vs. deep hierarchy can of worms. In this case, the deep hierarchy is a component in the JDK itself. :-/

* What do you think about prefixing/appending JVMOptions with entries read from NSDefaults?

I saw that a developer filed a bug trying to change his memory heap options and wanted to avoid breaking code-signing by modifying the app package. I've always found the concept of modifying the app bundle as fragile anyway, because the app can be on a read-only filesystem. I figured NSDefaults just "out of band" enough to be readable before the JVM starts, but still under the control of app through the java.util.prefs API.

Regards,
Mike Swingler
Apple Inc.