views:

427

answers:

3

I have an out-of-of-the-box software tool that I developed in Java. This software requires a fair amount of memory so it must be ran with the -Xmx1024M Java option otherwise it will crash. The customer will run a program named start.jar whose only command is to run the system command "java -Xmx1024M -jar myProgram.jar"

This has worked for Windows XP and Vista however the latest Java update for Windows 7 doesn't put the java/bin directory in the system path. This results in the command line reporting that java is not a recognized command.

My question is how to best resolve this issue? I realize I could give the customer instructions on how to put their java/bin directory in the system path however I think that is asking way too much(the target customer is not technically adept).

A: 

How about giving them a batch file to run? This could put Java in the system path if it's not already there and then launch java with the -Xmx1024M arg

royalsampler
The issue I see with this is determining what value to add to the system path. Most will have their bin directory in C:\Program Files\Java\jre6 however some will have it in the Program Files(x86) directory and others will have it in a different drive altogether. The other problem I am not sure how to handle is determining which directory to choose if they have multiple JREs or if a new version is released. Their Java folder may be named jre6 or it could be something like jre1.6.0_17.
juan2raid
+4  A: 

You could use a Java Executable Wrapper - like JSmooth or Launch4J.

Nate
A: 

Other than using the aforementioned suggestion of using an executable wrapper, I don't think there is any good solution for this that doesn't involve rewriting into a start script the kind of logic they already have in the wrappers. This tends to include searching the system path, Registry (HKLM\Software\JavaSoft\Java Runtime Environment) for "properly installed" versions, and "common locations" for JREs and picking an appropriate one based on what you've told the wrapper's config is the minimum JRE, whether to choose latest version etc. Rewriting this logic doesn't seem like a great use of time, but that depends on you :)

Another alternative (depending on licensing issues) is distributing a copy of the JRE alongside your application in a subdirectory so you always know where it is and what version it's using. Obviously this is slightly wasteful, and potentially means using software outside a normal desktop maintenance/upgrade cycle, but it might give you more control/convenience.

Chad