This week's giveaway is in the EJB and other Java EE Technologies forum.
We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line!
See this thread for details.
The moose likes Beginning Java and the fly likes 32 Bit to 64 Bit Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "32 Bit to 64 Bit" Watch "32 Bit to 64 Bit" New topic
Author

32 Bit to 64 Bit

Mark Reyes
Ranch Hand

Joined: Jul 09, 2007
Posts: 426
Hi all,

I have programmed my application usually in 32 bit windows xp operating system. It uses a lot of threads and socket connections. Will there be any specific problem if I deploy my application in 64 bit winxp operating system?
It is a desktop app and uses swt as its toolkit.

I have read that java is write once run anywhere but I havent read any topic regarding this. Looking forward to your advice or useful links.

Thanks.


Sean Clark ---> I love this place!!!
Me ------> I definitely love this place!!!
Mark Vedder
Ranch Hand

Joined: Dec 17, 2003
Posts: 624

When you compile the code in the JDK, it creates class files of bytecode. This bytecode is not 32-bit or 64-bit specific. So it can run in either a 32-bit or 64-bit JRE.

When you download the JDK and JRE from Sun, there is a 32-bit and 64-bit version for Windows (at least for Java 5 & 6; Java 1.4.2 is only available in 32-bit). The Java 5 version is labeled jdk-1_5_0_16-windows-amd64.exe where as the Java 6 version is labeled jdk-6u7-windows-x64.exe. The Java 5 version will run fine on an intel chip. It was just at the time Java 5 64-bit first came out, only AMD had the 64-bit chips.

You can install either of these, or both (more on a moment as to why you might want to do this), on Windows XP 64 or Vista 64-bit. So if you run your app using the 64-bit JRE, it'll run as 64-bit.

The one caveat is that there is only a 32-bit version of the Java Plug-in. (This is explained on the Sun download site.) The Java Plug-in is what runs applets in your browser, and launches Java WebStart applications. So if you still want to be able to run those, you need to install the 32-bit version of the JRE so the plug-in installs. You can then also install the 64-bit JRE so standard apps (i.e. non applets and WebStart apps) run as 64-bit. If you do that, I'd recommend installing the 32-bit version of the JRE first, then the 64-bit. Or installing the 32-bit JRE and than the 64-bit JDK, installing the JRE along with it.

I hope that helps.
Mark Reyes
Ranch Hand

Joined: Jul 09, 2007
Posts: 426
Hello, thanks for the very quick reply..

I did learned a lot from your post. When I downloaded the JDK before, I dont know that there was a 64 bit version for windows.

What I did was to install this version jdk-6u1-windows-i586-p.exe in the 64 bit windows xp machine. From what I have learned from your post, this is a 32 bit version.

My application seems to be running as expected, I just notice that in the Task Manager that the java exe runs as javaw.exe *32.

You can then also install the 64-bit JRE so standard apps (i.e. non applets and WebStart apps) run as 64-bit. If you do that, I'd recommend installing the 32-bit version of the JRE first, then the 64-bit. Or installing the 32-bit JRE and than the 64-bit JDK, installing the JRE along with it.


I have no applets or webstarts in my apps.

I just have one more query, if I will remain in my current setup (installed a 32 bit jre in a 64 bit os) will there be any problem or tradeoffs in my current apps? Or the best and efficient way is to download the 64 bit jre version and install it in my target desktop.

One more thing, that keeps me thinking also is that I use SWT as my GUI toolkit instead of the standard SWING toolkit. I am not sure if there will be problems that I have not foreseen.

Also, I am thinking about what you have said that my app may not run as 64 bit since my jre is 32 bit. I may not be utilizing the full potential of my operating system. Any views on this, Thanks again.
Mark Vedder
Ranch Hand

Joined: Dec 17, 2003
Posts: 624

Hello, thanks for the very quick reply..

I did learned a lot from your post.

Glad I could help.



What I did was to install this version jdk-6u1-windows-i586-p.exe in the 64 bit windows xp machine. From what I have learned from your post, this is a 32 bit version.

Correct

My application seems to be running as expected, I just notice that in the Task Manager that the java exe runs as javaw.exe *32.

Yup. In case I didn't explain that well in my previous post, you can run things under the 32-bit JRE on a 64-bit OS without any problems.

I have no applets or webstarts in my apps.

That's more of an 'issue' for web surfing than your own apps. Some sites use Java applets -- bank/financial sites commonly use applets (as well as other sites). And the Java Tutorial uses Java WebStart heavily to launch the sample programs. (And of course there are other sites that use Java WebStart).


I just have one more query, if I will remain in my current setup (installed a 32 bit jre in a 64 bit os) will there be any problem or tradeoffs in my current apps? Or the best and efficient way is to download the 64 bit jre version and install it in my target desktop.


I once searched for information on the subject, but didn't find much other than some anecdotal reports of things in forums; people reported that things seemed a bit more "peppy" (for the lack of a better term) under the 64-bit JRE. But that may just be artifical perception; a placebo effect if you will. Per the documentation for the java command:

On a 64-bit capable jdk only the Java HotSpot Server VM is supported so the -server option is implicit. This is subject to change in a future release.


So the JRE will run in server mode as opposed to client mode. As stated on the Server-Class Machine documentation page (emphasis added):


Starting with J2SE 5.0, when an application starts up, the launcher can attempt to detect whether the application is running on a "server-class" machine and, if so, use the Java HotSpot Server Virtual Machine (server VM) instead of the Java HotSpot Client Virtual Machine (client VM). The aim is to improve performance even if no one configures the VM to reflect the application it's running. In general, the server VM starts up more slowly than the client VM, but over time runs more quickly.


The section on 64-bit of the Frequently Asked Questions About the Java HotSpot VM page, and in particular the question what are the performance characteristics of 64-bit versus 32-bit VMs? talks more about this. The ironic part, as the answer to this FAQ points out, is that you might actually get some performance degradation in the 64-bit JRE because of the fact that:
"...every native pointer in the system takes up 8 bytes instead of 4. The loading of this extra data has an impact on memory usage which translates to slightly slower execution depending on how many pointers get loaded during the execution of your Java program. ... On AMD64 and EM64T platforms this difference ranges from 0-15% [degradation] depending on the amount of pointer accessing your application performs. " (more detail in the answer to this question at the site)


As a side note... when reading things on the page, just be aware that it frequently talks about 32 and 64-bit incompatibility of native libraries; these are C and C++ libraries that an application may use. Again, the actual Java bytecode is cross compatible.

One more thing, that keeps me thinking also is that I use SWT as my GUI toolkit instead of the standard SWING toolkit. I am not sure if there will be problems that I have not foreseen.


I don't really know anything about SWT... I know it uses JNI to access the native GUI libraries. So I'm not sure how that would affect things. Maybe some other Comp Sci guru would know.

Also, I am thinking about what you have said that my app may not run as 64 bit since my jre is 32 bit. I may not be utilizing the full potential of my operating system. Any views on this, Thanks again.


As mentioned above, if you are using a 32-bit JRE (as evidenced by the java.exe*32 in Window's task manager), its running as 32-bit. But I don't think you are going to notice any major differences either way. And as mentioned above, using the 64-bit will cause the JRE to run in server mode, which has a [minor] slower startup time, and then on top of that, the 64-bit JRE may result in a performance degradation. So I'd say, unless you have a compelling reason, to switch, you're fine staying with the 32-bit. (I'd be curious if any of the above will change with Java 7.)

Again, perhaps someone else has some more detailed information on the subject, or can point to some good articles on the matter.

I hope that helps.
[ August 06, 2008: Message edited by: Mark Vedder ]
Mark Reyes
Ranch Hand

Joined: Jul 09, 2007
Posts: 426
wow! such a detailed explanation.. Thanks again..

I did google about the effect of 32 bit to 64 bit but cant find a detailed resource on this one.

Anyway, thanks again.. I will look into the links that you have sent.

I will post a question again once I notice something strange.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: 32 Bit to 64 Bit
 
Similar Threads
Need starting point
Wrapper.Createfile failed with error 1224
libdmcl40.so: wrong ELF class: ELFCLASS32 (architecture word width mismatch)
Detect which kind of JRE is installed - 32 or 64 bit
Maximum allowed memory for Tomcat 6.0 and Tomcat 7.0