changing the memory settings semi-dynamically vs GateKeeper and signing

[Hendrik Schreiber]

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.

Thanks,

-hendrik