Eric Daly

Sorry for the late reply. I finally had a chance to test out that package you're trying to install, and I had the same problems you ran into. I was able to resolve the problem by first downloading and installing the standard JDK (which includes the JRE), and then I was able to install the JDK EE package by just double clicking it (I didn't have to run anything from the command prompt). The JDK EE installation found the JRE automatically and opened a nice GUI installer as expected. Let me know if that helps!

I'm not sure about that book, but I got a good start with Java by reading "Head First Java 2E" which was unlike any book I had ever read before. I had some background in C/C++, but I still think that book was the easiest way to learn Java. I know it's a bit outdated at this point, but it's still a good read and will get you started on the right path (and it's not overly expensive!).

Installing the JDK includes the installation of the JRE. You don't need Java to install Java, that wouldn't make any sense. Did you try just double clicking the .exe file instead of running it from the command prompt? That's usually the best method of installation unless you need other specialized options such as silent installation.

I don't see anything about a -j option for installation. Here's the documentation for installing the JDK silently if that's what you're after. The proper way to silently install is the "\s" switch, instead of -j. If you want to specify where to install, use "jdk.exe /s /INSTALLDIRPUBJRE=C:\test\" where C:\test\ is the directory you choose.

Hi,

I found this bug filed back in 2006. Why is it that when you call System.getProperty("os.arch") on a 64 bit version of Windows using a 32 bit version of JRE, it returns x86? Can anyone explain to me why this is not considered a bug? I only ask because "os.name" returns the operating system's name, "os.patch.level" returns the operating system's service pack level, so why does "os.arch" return the JRE's architecture? It's inconsistent, and very misleading. They shut down this bug report stating that it's "Not a Defect." Then what is it?

EDIT:
While looking through the documentation for OperatingSystemMXBean, I found the getArch() method, which "Returns the operating system architecture. This method is equivalent to System.getProperty("os.arch")." They are blatantly stating that this will return the operating system's architecture, while clearly it only returns the architecture of the currently running JVM. Sorry to go on such a rant here, but I think this is ridiculous!

I know it's been quite a while, but I wanted to post my solution to this problem. I needed to get this program working, so I whipped up a C++ program that basically just takes the command line arguments you pass into it, and executes them (assuming the first command is the fully qualified pathname to some type of executable file). This then worked for any type of file, including .msi. Then I realized that rundll32 does exactly the same thing (plus more), so I was just wasting time in C++. Anyway, all I had to do was this:
try { Runtime run = Runtime.getRuntime(); run.exec("rundll32 SHELL32.DLL,ShellExec_RunDLL msiexec /qb /i C:\\flash_ie.msi REBOOT=ReallySuppress"); } catch (Exception e) { e.printStackTrace(); }
And I found that tutorial I needed: http://www.rgagnon.com/javadetails/java-0014.html
I hope this helps anyone else who might be reading this.

Hah, well thanks for the advice. I wouldn't mind a tutorial... But maybe I should write one (once I get all these things straightened out of course). I'll have to check out that link, I've seen it before but never read through it. I'll definitely decide which approach to take, either by trying to use the start command (thanks for clearing that up) or using some other method in the case of msi files. I'll post my solution when I find it!

It's too bad there isn't more documentation (or there isn't adequate documentation, depending on how you look at it) on the ProcessBuilder class. In my opinion, there just isn't enough information, because I can't find any help anywhere with this other than trial and error, and asking other people based on their own experience. What does ProcessBuilder's start() method do exactly? It certainly won't run msi files, at least in my case:
File tempDir = new File(workingDirectory); if (tempDir.exists()) { for (Program temp : programList) { temp.setCanonicalPath(workingDirectory); } try { for (Program installer : programList) { name = installer.getName(); JOptionPane.showMessageDialog(null, installer.getCommandString()); ProcessBuilder p = new ProcessBuilder(installer.getCommandList()); Process proc = p.start(); proc.waitFor(); JOptionPane.showMessageDialog(null, "Successfully installed " + name); } } catch(Exception e) { JOptionPane.showMessageDialog(null, "Couldn't find " + name); } } else { JOptionPane.showMessageDialog(null, "Can't find Standard Software directory!"); }
where the working directory is C:\Documents and Settings\Owner\Desktop\Standard Software\ (this does exist, and my program works with any program in there that is an exe extension)
Program is a class I wrote that contains information about a program, including a name, an ArrayList<String> containing each command to use to install it (which I just pass in to ProcessBuilder's constructor). I get this by calling getCommandList(). getCommandString() returns the full path and command arguments that it's going to try to install (which displays correctly for everything, but only proceeds to work correctly with an exe file). An exception is thrown whenever trying to execute an msi file using ProcessBuilder, and then my program tells me it couldn't find the program (which isn't necessarily true, but the program here assumes that is the case). proc.waitFor() is used for two reasons: the first is to wait for the program to actually finish before reporting that it successfully installed, and the other is so that I can check the return code of the program and report on that (not included in this code).

Anyway, I hope that's enough background and clarification to let you know that there isn't just a bug in the code or something (well at least I don't think there is). I'll have to research the Desktop.open() solution, and see if there's a way to check the return code in that case, etc. I don't know anything about using rundll32, so I can research that one too, but I was really hoping to not even have to do it the old way by using Process and getRuntime because ProcessBuilder is a lot easier to manage (or is it?). Again, just in case anyone can help me out with this, what does ProcessBuilder's start() method really do behind the scenes? Are there really resources out there that explain any of this?

Hi,
I'm trying to create a Java app that can read in a file that contains a list of software programs and the command line arguments to install them silently. Then my app will run the programs and make sure nothing goes wrong. It's working so far, but now I'm trying to install an Windows installer called AppleApplicationSupport.msi, and my Java app is unable to run it... is there a way to do this, or do I need to somehow extract the .exe files from the .msi installers? Thanks.

You know what? That's a perfect solution! Thanks for the tip! I wonder why I didn't find out about that before... I better read the manual next time.

Hi,

I'd like to use ProcessBuilder to initiate installations of other programs, like Adobe Reader, by reading something in like an ini file which would contain data similar to the following format:
AdobeReader.exe /sAll /rs /l /msi /qb- /norestart EULA_ACCEPT=YES AgreeToLicense=Yes
So then my program would read that in (I know how to tokenize everything), and pass that data into a ProcessBuilder object. I've found that putting all of those commands into one "command" when creating a ProcessBuilder object doesn't work. You have to separate each command line argument into a separate ProcessBuilder command (from my experience). Since that's the case, how can I write my program to determine the right number of arguments to pass in and then create that ProcessBuilder object on the fly with an unknown number of command line arguments (at compile-time)? In case anyone is wondering, the only idea I have for now is to have something like a template for creating ProcessBuilder objects that I call based on the number of arguments passed in (and possibly have a limit on the total number of arguments), then call the right method basically based on that number. Isn't there a cleaner solution?

So it turns out that you have to specify the path (at least in my case) when creating the ProcessBuilder object (versus changing the working directory later).
private void runPrograms() { try { String newLine = new String(System.getProperty("line.separator")); String workingDirectory = new String(System.getProperty("user.dir") + "\\Standard Software\\"); File tempDir = new File(workingDirectory); if (tempDir.exists()) { String flashPlayer = new String(workingDirectory + "Flash_IE_32.exe"); try { ProcessBuilder process = new ProcessBuilder(flashPlayer, "-install"); Process p = process.start(); int flashPlayerExitCode = p.waitFor(); if (flashPlayerExitCode == 0) { JOptionPane.showMessageDialog(null, "Flash Player installed successfully!"); } else { JOptionPane.showMessageDialog(null, "Flash Player Exit Code: " + flashPlayerExitCode + newLine + "Something went awry during Flash Player installation!"); } } catch(Exception e) { JOptionPane.showMessageDialog(null, "Flash Player installation failed!" + newLine + "Couldn't find \"Flash_IE_32.exe\" in the Standard Software directory."); } } else { JOptionPane.showMessageDialog(null, "Can't find the Standard Software directory!" + newLine + "Program will now exit."); } } catch (Exception e) { JOptionPane.showMessageDialog(null, "Something has gone awry while running the processbuilder class!"); } }
If you create the ProcessBuilder object first, and then try changing the working directory, apparently the program is still going to try to run from wherever the ProcessBuilder object was created, unless you specify the path at that point. If that really is the case, then in all honesty I just don't understand what the point of changing the working directory is. I mean, isn't it completely useless? Can somebody please explain what it actually DOES? It doesn't do anything for me... I don't mind, as long as there's a way to run programs outside of the current directory (which I finally found), but I just want to know what is really happening behind the scenes of ProcessBuilder. I've googled this to death, and can't find any clear cut examples (you've gotta admit, the examples from Sun aren't the best).
ProcessBuilder pb = new ProcessBuilder("myCommand", "myArg1", "myArg2"); Map<String, String> env = pb.environment(); env.put("VAR1", "myValue"); env.remove("OTHERVAR"); env.put("VAR2", env.get("VAR1") + "suffix"); pb.directory("myDir"); Process p = pb.start();
So... what's VAR1, myValue, OTHERVAR, VAR2, and suffix? Am I really just completely missing the point here, or can somebody else testify that this example is pretty confusing? I need more documentation...

Not to take away from the whole gui idea here, but there's just that whole element of gameplay that you take away when setting everything in stone using a gui to present a limited set of choices. There's a fun factor in guessing what you have to type, like figuring out that you have to swing a sword in a room to break a pot, or use a certain key in a certain lock, as opposed to clicking one of three options (without having to think about it much) that will quickly progress you through the game. I'm all for approaching this from the command line, and even with having to code the parsing mechanism, it can be just as manageable of a solution as doing it through swing (in my opinion), and possibly even more fun. Or at least let the user type commands in through the gui, versus having a few button choices. That way you solve the problem of opening the command prompt from the executable jar.

Well, when I run the jar from the desktop, it finds that directory and displays a message stating that the working directory is C:\Users\Eric\Desktop\Standard Software
Based on my understanding, user.dir is giving me my current directory, wherever I run my program from. So yes, I'm expecting it to run that program that's in the standard software folder on the desktop. For some reason it's still trying to run the program directly from the desktop, even though I clearly have changed its working directory to standard software and verified it. I really don't understand what I'm doing wrong here, I already tried explicitly setting the directory manually, but it still does the same thing. What am I missing?

I'm trying to run executable windows installer files from Java using ProcessBuilder. I've got it to work when the program is in the same directory as the java program, but when I try changing the working directory using ProcessBuilder's directory(File directory) method, my program fails. Here's my code so far:
import java.io.*; import javax.swing.*; public class processbuildertest { public static void main(String[] args) { try { ProcessBuilder process = new ProcessBuilder("Flash_IE_32.exe", "-install"); File userDir = new File(System.getProperty("user.dir") + "\\Standard Software"); if (userDir.exists()) { process = process.directory(userDir); File temp = process.directory(); String currentWorkingDirectory = "Current working directory: " + temp.toString(); JOptionPane.showMessageDialog(null, currentWorkingDirectory); process.start(); } else { JOptionPane.showMessageDialog(null, "Can't find Standard Software directory!"); } } catch (Exception e) { JOptionPane.showMessageDialog(null, "Something has gone awry while running the processbuilder class!"); } } }
So then I create an executable jar, copy it to the desktop, and run it. I have a folder called "Standard Software" on my desktop with a program labeled "Flash_IE_32.exe" in it. When I run the jar, it finds that the directory exists, displays the current working directory, and then throws an exception when trying to start the process. I copied that installer to the desktop, and then my program runs fine. So my question is, how do I REALLY change the working directory? Or how do I run a file from any other directory, since obviously changing the working directory is completely useless (unless I'm doing something wrong, which I realize that I am )?