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

[Greg Brown]

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

Not sure yet.

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

Cool. If you think the proposed key names make sense, I'll make that change.

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

I had considered recursively scanning the directory structure for JARs, but decided to defer it for this release since I wasn't sure how much value it would add.

I hadn't planned on re-introducing support for macro expansion. I'd like to understand the possible use cases better. If it is literally just a way to extend the classpath, there are other ways of doing so within the existing design - for example, by passing a custom <option value="-Dclasspath=…"/> tag to the Ant task, or by manually modify the generated plist post-generation.

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

Seems like it would be worth considering. Maybe something to come back to in the next rev?

G