I have a program using JDK 1.7 running on Windows Server 2008 (32 bits). If I want to re-deploy the program to the latest Windows Server (64 bits), do I need to rewrite the program or just minor change is ok?
Thanks a lot!
Short answer
No, you should not need to change your code. You don't even need to recompile it. Just run your JAR/class and it should work fine.
You didn't provide much details of your application, so I ask you to read the long answer for more info, since there are considerations which might help you in the future.
Long answer
The Java Compiler generates bytecodes which are later interpreted by the JVM. The JVM translate the bytecode into native commands. The JVM will do the "hard work" while you can focus on one single program. The Java platform is platform independent, therefore you should not need to change your code if you are going from 32 bits to 64 bits Windows.
As always, there are some exceptions, which go beyond the 32/64 bits case. I will list some for example:
Breaking lines in Linux and Windows while working with persistence (MS files usually have carriage return)
Using JNI to consume native libraries (This might impact 32/64 bit programs)
Fonts used on different operational systems
Maybe some Java bug, but very improbable
As a general practice, if you are going to cross platform your application, try to find the "boundaries" of your program. When do you have go "outside" your application to seek specific OS resources?
Even if your program runs in an application server, such as JBoss, you should not need to change your code.
I think your program will work fine without any changes, just keep in mind that exceptions may apply.
I don't think you need to change anything. Do you use any native code through jni?
First, are you using JDK or JRE on the 32 bit Windows? You just need JRE to run your application.
Second, on Windows 8, you can still install 32 bit JRE so your application should run.
Third, if you installed 64 bit JRE, your application should still run. There might be more bugs in 64 bit JRE. If you encounter a lot of bugs, just use 32 bit JRE instead.
Related
I've recently been experimenting with Processing (https://processing.org/).
It's a sort of IDE used to make GUI design in Java easier. Since I'm not a fan of swing or AWT, I found it quite fun to use.
Something interesting to note though. When I "export" the Application for windows, it creates both a 32-bit and 64-bit version.
I'm a little confused as I thought after Java source code is compiled to Java bytecode, it can be run anywhere as long as that place as a JVM. (Write once, run anywhere).
So why are both a 32 bit and 64 bit version of the app created? Shouldn't the bytecode be platform independent and only be translated using Just-In-Time compilation to whichever architecture the JVM is on, during runtime? At least, I know that's how .NET does it with the CLR.
I'm going to attempt to answer my own question by saying since the applications created are .exe files, the translation to native architecture happened ALREADY, since windows was specified as a target-platform...I guess to increase efficiency?
Otherwise, I'm confused. The only time I've seen a compilation happen twice is when I was programming C++, and needed to compile twice for 32-bit and 64-bit.
Thank you!
Processing is built on top of JOGL which is (basically) a Java wrapper of OpenGL, which is a device-specific graphics library.
Also, Processing (can) include a whole JVM with its exported applications, so end users don't have to worry about downloading Java. The JVM itself is OS-dependent, so the exported application is as well.
You can confirm this by taking a look at the files that Processing creates. Specifically, notice these files:
jogl-rt-natives-windows-amd64.jar
jogl-all-natives-windows-amd64.jar
These .jar files contain the native files required by JOGL.
Full disclosure: this is a federal computer/system so I have limited capability to make significant changes, but our federal "Enterprise" service desk of course does not know what is happening, so, I'm here.
I have a 64 bit operating system set up due to setting up ODBC connections to work with various programs which includes R 64 bit (this is the set up we were told we needed for all the systems to work). I of course also need Java 64 bit in order to use many of the R packages available nd have installed 64 bit Java multiple times, while sometimes removing and sometimes leaving 32 bit Java installed. Everything works fine for a while and I'm able to use the packages requiring Java by setting the Java environment path as necessary. No problems there.
The issue comes a few hours/one day later when my entire system shuts down with no notification at all (all programs just shut down while I'm actively working in them). The system reboots itself, 64 bit Java is uninstalled and 32 bit Java is reinstalled (regardless of whether I had uninstalled the 32 bit version or not) and I'm left to reinstall 64 bit, which works for a few hours before the whole process repeats itself.
I can't find anything anywhere for the same issue so... Anyone have any ideas? Our service desk basically just told me our systems only force reboots for Windows updates and and don't have any idea what is happening.
Edit: This is Java 1.8.0_111 although I've had the same issue with previous updates of Java 8.
Edit 2: No one else is having the same issue and are having no trouble with 64 bit Java on their computers. I'm special.
I wanted to know Will the Java desktop application running on Windows XP also run as it is on Windows 7 or need any modification in program?
Theoretically java is platform independent and should run on any Windows, any linux, any mac etc without any modification exactly the same. Practically you have to check that you do not use any platform dependent features or parameters.
For example:
JNI
Execution of platform specific command line tools
Platform specific file paths
Communication with platform specific processes/services
Operations that can produce security issues on some Operating systems (e.g. specific file paths, registry entries under HKLM on windows 7,8 etc)
Assumptions about line, path, file path separators (\r\n vs \n, \ vs '/', ; vs :)
Wrong usage of layout managers that can cause UI to fail on some screen resolutions.
Yes. It will definitely work. Try it and if got any errors send us for review.
Java is Platform Independent.
You can use that application in any OS.
In stand alone application, Java source code is converted into byte code . So Java is platform independent.
Java's claim is to be a WORA (Write Once, Run Anywhere) language.
Assuming that Windows 7's JRE hasn't introduced any new bugs and assuming your code is straight-forward Java that doesn't rely on JNI, manipulating Windows XP specific registry keys, etc., the answer is a definite yes. It should run smoothly.
Yes, thanks for the JVM (Java Virtual Machine) it will act the same on different platforms ...
It seems to be a simple question, but I wasn't able to find a meaningful answer, only a lot of speculations.
Also, if an answer is yes, which JVM would it be, Oracle's or again something patched by Microsoft?
Specifically: I have a Java desktop application, running on JRE 7, would it run on WinRT?
I mean, can I install JRE 7 on WinRT? Would it run without problems?
Yes and no.
It would certainly be possible to implement a Java Virtual Machine, or at least a substantial portion of one, using the Windows Runtime APIs and the portions of the Windows API that are usable from a Windows Store app. However, such a JVM would need to be an interpreting JVM, not a JIT compiling JVM. JIT compilation requires the ability to change memory protection (to allow execution of generated code), but the APIs to change memory protection (VirtualProtect and friends) are not callable from user code in a Windows Store app.
So, could you implement an interpreting JVM usable in a Windows Store app? Probably. Whether or not it would be possible to implement a JVM that performs well enough to be usable is another matter altogether, though.
i have developed a desktop application for my college project. I developed in 64 bit machine with NetBean IDE 7.0.1 of 32 bit and i have JDK of 32 bit, project runs perfectly form NetBean but when i converted into .jar it did not work, but same .jar file works in 32 bit machine. Anyone have idea about this thank in advance.
Under normal circumstances, you can take code developed on a 64 bit machine and / or a 64 bit JVM, and run it on a 32 bit JVM ... and vice versa. This applies whether or not you are using a JAR.
The fact that you are having trouble says that you've done something wrong. However, without some more information, we'd be wasting our time speculating on what that might be. "It did not work" is not enough to go on. (It is like going to a doctor and saying, "I'm not well" and expecting him to cure you on that basis alone.)