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

[Mike Swingler]

On Feb 20, 2012, at 12:16 PM, Greg Brown wrote:

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

JVMRuntime, JVMMainClassName, JVMOptions, and JVMArguments sound like good names.

It also sounds like there is demand for a JVMClassPath as well (which would logically necessitate a form of macro expansion to be able to reference inside the app bundle). Perhaps if a JVMClassPath were specified, you could turn off the automatic flat-directory scanning, to keep the rules simple and predictable.

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

As has been pointed out to me, there are many people in the community who consider flattening their filesystem hierarchy to be an unacceptable burden. I don't agree with it, but perhaps a JVMClassPath option will enable them to do what they want.

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

I think you are losing something behind that little "…" there: the classpath that enters the JVM needs to be fully qualified paths, or relative to the working directory - which for bundled app is "/". That sucks.

To refer to any resource inside your app bundle on the classpath, I think it's required to do macro expansion.

While I understand the time pressures required to ship (and the annoying cacophony of voices, of which, I'm sure mine is one of the more obnoxious), I think it's perfectly acceptable to say no to a JVMClassPath option for v1, and take these as feature requests for v2 - knowing that it's a trade off that apps like NetBeans probably won't adopt the v1 implementation.

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

Sounds great. I think the guy filed a bug, so it's on the books.

Regards,
Mike Swingler
Apple Inc.