|
Technote 1168The Care And Feeding of Runtime.execBy Jens Alfke Sample code by Levi Brown |
CONTENTSThe Platform-Dependent Perils of | R untime.exec( ) is probably the single least cross-platform-compatible part of the Java API set. It assumes the existence of a command-line interface to the OS and the ability to launch arbitrary apps that can accept arbitrary parameters. Nevertheless, there are times when you need to use it -- for instance, to open a URL in a Web browser or to spawn a new Java process. This technote describes MRJ 2.1's implementation of |
The Platform-Dependent Perils of |
The Path To The AppThe Mac OS has no search path, so you must specify an application using a real file path. For example, just referring to the application as " Relative pathIf the application you're launching is at a known location relative to the application running (i.e., both are part of the same installation) you can provide a path that's relative to the current application. This works reliably only if you're running an application built with JBindery, not if you run your code directly from JBindery itself. User preferenceIf the app to launch is not part of your installation (for instance, if it's something standard like SimpleText or a web browser), you'll need to provide an absolute path. The most reasonable cross-platform way to do this is to store the path in a preference file. If the preference doesn't exist yet, or if you tried using the preferred path and it failed, you should put up a dialog box and ask the user to select the application, then store the path into the preference file. See Technote 1134, "The Preferences Problem," for more discussion about setting the correct path using a preference file. Lookup by creatorIf you're willing to use some Mac-specific code, it's friendlier to use the Mac OS facility to locate an application automatically given its creator code, which is a unique four-letter code assigned to that application. You can find the creator of any application by using ResEdit's
The MRJToolkit library, provided as part of the MRJ SDK (including extensive documentation) includes a
Let JConfig locate it for youThe third-party JConfig library from Samizdat Productions, described above, has features that can locate the user's preferred helper app for any type of URL, which is one of the common uses of |
Launching JavaIt turns out that one of the useful things you can do with In MRJ 2.1 we valiantly added some special cases (some say "hacks") to facilitate this. If the application/command named in the first argument does not point to an existing file, and it does include the substring "
For example, you can invoke the Java compiler thusly:
Since we know the thing on the other end is a Java process, we allow a bit more general functionality:
Special flags for ' |
Flag | Purpose | Status |
---|---|---|
| Prints help message & exits | Supported |
| Prints version & exits | Error |
| Turns on verbose mode | Error |
| Supported | |
| Sets system property | Supported |
| Prints help on nonstandard options & exits | Error |
| Enable remote debugging | Error |
| Disable asynchronous garbage collection | Supported |
| Disable class GC | Supported |
| Set max native stack size | Ignored |
| Set max Java stack size | Ignored |
| Set initial Java heap size | Ignored |
| Set max Java heap size | Ignored |
| Enable method profiling | Ignored |
| Enable instruction profiling | Ignored |
| Enable heap profiling | Ignored |
| Enable bytecode verification | Ignored |
Future versions of MRJ may support more of these flags.
* A note on |
Pasteurized ProcessesThe Most of these work as advertised, but the latter usage is problematic -- the Mac OS has no notion of text streams attached to applications, so it's meaningless to try to access them. MRJ just returns null if you ask The exception is Java processes, as described above. Since these are special processes that just run Java code, they do have console I/O streams, and the Process API allows you to access them. |
Example: Opening A URL In A BrowserHere's some sample code by Levi Brown that demonstrates a cross-platform-savvy way to open a URL in a Web browser. It presents a
This example should be refined, if used in a real setting, to store the location of the browser ( Alternatively, as described above, you could locate a browser by its application signature, or use JConfig to handle the whole open-the-URL process for you. |
AcknowlegementsThanks to kelly jacklin and Steve Zellers for explaining the details to me (and for implementing them in the first place!) and to Levi Brown of DTS for the sample code. |