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

[Mike Swingler]

On Feb 21, 2012, at 5:46 AM, Greg Brown wrote:

>> It...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)
> 
> I'd still like to get a better understanding of the possible use cases before committing to this approach. I'm reluctant to support any feature that allows a caller to specify a classpath outside of the bundle, since this will have a negative impact on portability and security.

I think specifying a classpath should always root to things inside the bundle. Perhaps disallowing paths that start with "/" would make this very clear. The examples I've heard are apps that deploy using another shell as a framework (SWT, NetBeans-shell, etc), who are not willing/able to change their on-disk layout. The example I more sympathize with is accessing tools.jar, which is in the bundle, because it's in the JDK, but it's not on the classpath.

>> 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.
> 
> As I mentioned on a related thread, the Ant task probably isn't going to be the solution to all deployment needs. There will undoubtedly be some apps whose requirements are simply too esoteric to be met by the task. However, the goal is that it will be suitable for the majority of use cases.

Would you recommend that an app that uses tools.jar use the Ant task to copy it into Contents/Java, or should it remain inside Contents/Plugins/1.7.0.jdk/Contents/Home/lib? If the latter, then it's possible the app could just bundle a 1.7.0.jre, and not the full JDK - but that would start to look more custom.

Regards,
Mike Swingler
Apple Inc.