2

I am running on a 64 bit installation of Windows 7 and am calling System.getenv("programfiles") which is returning C:\Program Files (x86) instead of C:\Program Files. I have also noticed that when I run the same code using run in IntelliJ it returns C:\Program Files like it should. I assume this is because it is inheriting environment variables from IntelliJ but I would like to be able to get both the 32 and 64 bit versions from a standalone application. What is causing this and what can I do to fix it?

user2248702
  • 2,741
  • 7
  • 41
  • 69
  • Is your code compiled using a 32-bit JDK or 64 bit? – Buhake Sindi Dec 05 '14 at 08:59
  • 2
    Usually an application is presented an environment based upon its bittyness. So a 32-bit application gets the 32-bit folder names and registry keys, while a 64-bit application gets the 64-bit pendants. – Thorsten Dittmar Dec 05 '14 at 09:02
  • @BuhakeSindi I am compiling with Maven which I assume uses JAVA_HOME which (should be) 64 bit but when compiling with IntelliJ which uses the same path as JAVA_HOME it works. – user2248702 Dec 05 '14 at 09:23
  • @user2248702 It has nothing to do with which java version you *compiled* your code with, but has everything to do with which java version you *run* your app in. System will always expose the properties from the configured JVM on which you are executing your code. – dubes Dec 05 '14 at 09:39

1 Answers1

1

The most probable reason for it returning x86 folder is that you are executing the standalone app with 32 bit JDK. Can you double check your JAVA_HOME and JRE_HOME environment variables? or do a quick java -version.

Also, perhaps this question will help: Java - get "program files" path

Community
  • 1
  • 1
dubes
  • 5,324
  • 3
  • 34
  • 47
  • I have unset my JAVA_HOME variable as the whole reason behind getting program files is to set the JAVA_HOME variable. I have never had JRE_HOME set to anything and java --version returns "Error: Could not create the Java Virtual Machine" I'm not sure what is causing this but I would assume it is because JRE_HOME isn't set. – user2248702 Dec 05 '14 at 09:13
  • It turns out I mistyped "version" and now it is showing 1.7.0_09 – user2248702 Dec 05 '14 at 09:17
  • 1
    @user2248702 does it show in the 3rd line of the output of java -version something like: "Java HotSpot(TM) 64-Bit Server"? – dubes Dec 05 '14 at 09:24
  • It says exactly that "Java HotSpot(TM) 64-Bit Server VM (build 23.5-b02, mixed mode)". (It won't let me tag you for some reason) – user2248702 Dec 05 '14 at 09:27
  • @user2248702 The tagging could be due to the lack of reputation. What confuses me is that if your java environment is 64 bit so I would expect that the output of System.getenv(...) to give ProgramFiles instead of Program Files x86. – dubes Dec 05 '14 at 09:37
  • I found http://stackoverflow.com/questions/2062020/how-can-i-tell-if-im-running-in-64-bit-jvm-or-32-bit-jvm-from-within-a-program which shows how to find bitness so I made a test program: gui.appendStatus("progfiles: " + System.getenv("programfiles")); gui.appendStatus("bitness: " + System.getProperty("sun.arch.data.model") ); which returns progfiles: C:\Program Files (x86) bitness: 32 when run by double clicking and progfiles: C:\Program Files bitness: 64 when running through IntelliJ. – user2248702 Dec 05 '14 at 09:47
  • I think I have at least found one cause of the problem, when I launch from the command prompt it shows 64 bit but when I launch by double clicking I get 32 bit. Is there some property in the manifest that sets what JVM to use? – user2248702 Dec 05 '14 at 09:50
  • @user2248702 You can't specify the version in the manifest. The execution environment is configured by the client. I think window is by default picking up your 32 bit java to open the jar. Try the steps given in this answer http://stackoverflow.com/a/8511277/1695393 to change the file association in windows to use the 64 bit javaw.exe From an end user perspective, you can warn them on launching the jar to use the correct version of java or handle the version checking on your side (depends on the usage) – dubes Dec 05 '14 at 09:58
  • Is there another way of getting program files? as the reason behind getting it is so the user does not have to set JAVA_HOME themselves. – user2248702 Dec 05 '14 at 10:08
  • @user2248702 No, users will need JAVA_HOME set in order to execute the JAR, you will have to warn them in your app or handle both 32bit and 64 bit solution. Let me know if you need more info, we can then plan and move to a chat session – dubes Dec 05 '14 at 12:24