views:

318

answers:

3

Hi,

I have a Java application which requires certain software (one of them being Perl) before it can be run. What I used to do to detect for Perl is:

Runtime.getRuntime().exec("perl Test.pl");

and if there was an IOException declare that there was no Perl.

However, one of my users complained that the app kept failing because he had not placed Perl in his path varible. So this is why I'm asking: Is there any cross-operating system way to detect whether Perl (or any other software) is installed on the user's system and the path to the program?

+5  A: 

These kind of questions seem to be popping out every now and then and the answer (almost) always is no. Most general reason for the negative answer is that Java is run in a homogenous Virtual Machine environment which is by design the same on all platforms; Those operations you can't abstract away/do reliably on at least the most supported platforms just can't be done easily. Detecting external events in the OS in general such as which non-Java applications are also run/installed falls into that "not easy to do" category.

Certainly there could be need/market for JNI libraries for the purpose but those steer heavily from the cross-platform requirement these questions always seem to want to and that's why the short answer is "no". As far as I can see, what you're doing currently is the cleanest way to detect Perl unless you're willing to include perljvm or similar in your project.

Esko
+3  A: 

If the user is not willing to either

  • Install perl in an agreed upon location
  • Indicate where perl has been installed by storing it's location in an environment variable, config file, windows registry, etc.

then it seems you're only option is to search the entire disk for an executable named 'Perl'. Obviously this could take a very long time, but if you store the location somewhere, at least you should only need to search for it once

Don
Oh geez, with Windows machines the latter could potentially take anywhere from 15 to 500 minutes :) +1 just for the insanity of the thought.
Esko
+1  A: 

I don't know your target audience (users), but upon failure you could prompt the user to enter the path (a FileChooserDialog) and then store this path for future usage (if the exception is not thrown again). I did that some time ago, luckily I had users that were SysAdmins, so it was OK for them to provide that info when the error happened the first time (I also documented how to update or change these values in a properties file).

Other option as mentioned by Don, is to install the required software as relative to your installation, that's a more common option.

Abel Morelos