mik3hall at gmail.com
Mon Feb 24 15:26:49 PST 2014
On Feb 24, 2014, at 5:15 PM, David DeHaven <david.dehaven at oracle.com> wrote:
>> Application. Signed, not sandboxed. Something recently, Lion -> Mountain Lion maybe? seemed not to work unless I signed it. So I self-signed. I first looked at this a while ago I think before it was even signed and still couldn't get it to work.
> I don't know what the core issue is but my own (personal) experience has been that LSEnvironment isn't reliable.
>> I'm trying to interface 3rd party code to my HalfPipe application. It's a JSR 223 interface to the R language.
>> It seems to require a R_HOME environment variable set. Which so far, I can't give it with LSEnvironment through the plist.
> Requiring R_HOME to be set in the environment seems sketchy to me. At worst you should be able to set it through a system property, not rely on the environment. Is it open source? Maybe it could be fixed and contributed back.
> The ugly workaround might be to drill down through JNI to call setenv, if it can be done early enough.
Given LSEnvironment not seeming to work at all. I should probably set up some other test cases and see if this seems to hold consistently.
But given that, I am already considering the workarounds. The property is required by the native code, getenv(), where System.property not quite as preferred as in Java? Anyhow, current efforts on the 'ugly workaround'. Somehow do a setenv myself.
trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz
HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe
AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter
More information about the macosx-port-dev