changing the memory settings semi-dynamically vs GateKeeper and signing

[Mike Swingler]

On Feb 20, 2012, at 12:17 AM, Hendrik Schreiber wrote:

> Hi,
> 
> I already posted this on the Apple java-dev list - Mike S. recommended taking this topic here.
> 
> Here's (more or less) the post from java-dev:
> 
>> I guess most of us who ship java applications ship them with explicit memory settings (-Xmx ...) in the Info.plist file.
>> 
>> Sometimes, while an application runs, you can recognize that the given heap simply isn't big enough. An application that does that is e.g. IntelliJ IDEA. It then allows you to manipulate the settings in Info.plist and to restart with the new settings.
>> 
>> With 10.8 we will all more or less have to sign our code (if you don't know why, just google GateKeeper). If I'm not mistaken, this will also sign the Info.plist file, meaning that a manipulation like IDEA's will be noticed and cause the system to reject the app, because it appears hacked.
>> 
>> Since I'm not aware of any other ways to manipulate max heaps size and friends, it becomes impossible for applications to adjust their memory settings semi-dynamically. This is a problem.
>> 
>> Perhaps the only way out of this dilemma would be to make the launcher read a second file, that is not signed and can therefore be manipulated, which contains all the command line options that we'd like to manipulate for the next app start.
> 
> I filed a corresponding bug - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146890
> 
> What do you guys think? I'm no expert in this in using codesign. Are my assumptions correct?
> And is this something that could/should be built into the launcher? And if so, how?
> 
> Thinking about this, I kind of like the idea of being able to control an app on a per user level. Much like through .rc files.

This could also be done elegantly by having the JavaAppLauncher use the NSDefaults API so the values can be changed using a simple "defaults write" at the command line, and possibly, using a modification of the Java preferences API itself (which is backed by CFPreferences).

Regards,
Mike Swingler
Apple inc.