32-bit or 64-bit Processing?
in
Integration and Hardware
•
10 months ago
A good article to help you to choose:
http://java.dzone.com/articles/should-i-use-32-or-64-bit-jvm
In short: unless you need to use really lot of memory (more than 1 GB), there is no compelling reason to use a 64-bit JVM.
Which can be problematic if you try to use a library with a native part (ie. a .dll or .so or similar file) which might not have a 64-bit version.
Note that if you have an old 32-bit system, you have no choice but using the 32-bit version of Processing. (AFAIK)
If you have a 64-bit system, you can use either: a 32-bit JVM works well on such system.
Actually, you probably can even install both JVMs, they can coexist peacefully.
The following information is for Windows, as I have no experience with other OSes.
If you installed both JVMs (I recommend to install them via the JDKs, for programming purpose), the system one, answering when you type java -version on the command line, and copied to C:\Windows\system32 (java.exe, javaw.exe and javaws.exe) is the last one you installed.
The 32-bit version will be copied to C:\Program Files (x86)\java\jre6 (or jre7) while the 64-bit version will go to C:\Program Files\java\jre6 (or jre7). The latter name can be localized on your system (it is displayed as C:\Programmes on my French system, but a dir command still lists it as C:\Program Files.
With Processing 1.5.1, if you downloaded the Java-less version or if you removed the java folder in the Processing installation directory, it will use the system Java (the one in system32).
Processing 2.0b6 only comes bundled with its own version of Java (1.6.0_33). If you remove (or just rename, as safeguard...) the java folder, it will complain (actually, that's launch4j): " This application was configured to use a bundled Java Runtime Environment but the runtime is missing or corrupted.", and I saw no obvious way (eg. some config file) to convince it to use the standard JRE...
If you have additional information to share here, don't hesitate!
http://java.dzone.com/articles/should-i-use-32-or-64-bit-jvm
In short: unless you need to use really lot of memory (more than 1 GB), there is no compelling reason to use a 64-bit JVM.
Which can be problematic if you try to use a library with a native part (ie. a .dll or .so or similar file) which might not have a 64-bit version.
Note that if you have an old 32-bit system, you have no choice but using the 32-bit version of Processing. (AFAIK)
If you have a 64-bit system, you can use either: a 32-bit JVM works well on such system.
Actually, you probably can even install both JVMs, they can coexist peacefully.
The following information is for Windows, as I have no experience with other OSes.
If you installed both JVMs (I recommend to install them via the JDKs, for programming purpose), the system one, answering when you type java -version on the command line, and copied to C:\Windows\system32 (java.exe, javaw.exe and javaws.exe) is the last one you installed.
The 32-bit version will be copied to C:\Program Files (x86)\java\jre6 (or jre7) while the 64-bit version will go to C:\Program Files\java\jre6 (or jre7). The latter name can be localized on your system (it is displayed as C:\Programmes on my French system, but a dir command still lists it as C:\Program Files.
With Processing 1.5.1, if you downloaded the Java-less version or if you removed the java folder in the Processing installation directory, it will use the system Java (the one in system32).
Processing 2.0b6 only comes bundled with its own version of Java (1.6.0_33). If you remove (or just rename, as safeguard...) the java folder, it will complain (actually, that's launch4j): " This application was configured to use a bundled Java Runtime Environment but the runtime is missing or corrupted.", and I saw no obvious way (eg. some config file) to convince it to use the standard JRE...
If you have additional information to share here, don't hesitate!