OpenJDK writes to ~/Library/Caches/?

[Mike Swingler]

On Dec 3, 2011, at 12:39 AM, Tobias Bley (UltraMixer) wrote:

> Hi,
> 
> I tried to submit a java application based on OpenJDK7 to the App Store. After fixing several issues now I get the following error:
> 
> 2.30
> 
> The application accesses the following location(s):
> 
> '~/Library/Preferences/net.java.openjdk.cmd.plist'
> '~/Library/Caches/net.java.openjdk.cmd/com.apple.opencl/com.apple.ocl.32.maps'
> '~/Library/Caches/net.java.openjdk.cmd/com.apple.opencl/com.apple.ocl.32.data
> '~/Library/Caches/net.java.openjdk.cmd/com.apple.opencl'
> '~/Library/Caches/net.java.openjdk.cmd'
> '~/Library/Caches/net.java.openjdk.cmd/com.apple.opencl'
> 
> Does anybody know how to prevent writing to this location?

It appears the JDK you are using is running a command-line tool, and it needs to use a different CFBundleIdentifier to access it's resources. Can you use a derivative of the JNI launcher at <http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/file/default/src/macosx/bundle/JavaAppLauncher/> as your primary executable?

What is literally happening at the lowest level is that each of the command-line tools in the JDK is compiled with an Info.plist embedded into it's Mach-O binary. This Info.plist is consulted by CFBundle when it needs to figure out the "app" bundle ID and relative location. The only way to fix this value up to the "correct" value is for your app's primary executable to be real Mach-O binary which loads the JRE, and to not use the */bin/java tools (which you can feel free to strip out of your bundled .jre).

If you are bundling something like an IDE, and really need the command-line tools to work, you'll need to rebuild the JDK with your apps bundle identifier instead, so it will access only your apps sandboxed resources.

Regards,
Mike Swingler
Apple Inc.