If your app need to use environment variables to configure something for runtime it is probably best to have your own stub launcher and launch a sub-process.
It can be tricky to have a smooth user experience with that though. You would want to avoid an extra icon in the dock/start bar. You don’t want the other process to show up as “java.exe”, etc. That’s the benefit of trying to solve this in the launcher created by jpackage. Scott > On Sep 2, 2020, at 11:59 AM, Michael Hall <mik3h...@gmail.com> wrote: > > > >> On Sep 2, 2020, at 9:04 AM, Andy Herrick <andy.herr...@oracle.com> wrote: >> >> Yes - environment variables are not a good answer for this, not just mac, >> but even on windows the env variables at run time are different if launched >> from a shell (the env variables of that shell) vs. when run from a shortcut >> (the system-wide or user env variables set in Control Panel or Settings >> dialog). >> >> JEP-343 says jpackage should be "a tool for packaging self-contained Java >> applications.", so an app packaged with jpackage should run on a machine >> without requiring any other files to be installed . That should not >> prohibit optional configuration from being discovered on a machine and used >> to tune the application or it's use of Java. >> >> Normally, any such discovery can be done by the application itself, except >> where it is the the java options that tune the java vm itself, and that is >> why we are considering mechanisms (such as expanding environment variables >> at runtime, or reading an installed configuration file of some kind) >> > It’s difficult and was difficult with java applications on OS X from the > start to have an application support anything like command line invoking with > parameters. > > Maybe add standalone options for the command that update an existing > application bundle? Of course then there would probably be signing and other > issues. > > Again, for LSEnvironment on OS X I think it wouldn’t be terribly difficult to > implement. You could handle it something like it appears file associations > work. Although, I haven’t done anything with those yet. Then just modify the > Info.plist. I have had code that does that in the past. XML right? > > In the past I have had need to add environment variables to my application to > interface it with the R language. Also debugging AppleScript related at one > point required environment variables. It was very much an OS X only java app > at one point in time. > Recently I had problems interfacing to Anaconda python that it seemed like > being able to set the PATH variable might resolve. Although my own attempts > to set the variables to get it to work failed. What did work was command line > shell invoking the application. Like myApp.app/Contents/MacOS/myApp from > Terminal. That was for someone else’s application. > I decided just to set a alias for that in .bash_profile for my own use and > not try to figure what exactly the Finder launched application needed to make > it work. > So these are some use cases where environment variables were involved. A > feature to support them could occasionally be nice. > > > > > > >
