Does any weird errors comes when the code is compiled with one Java version and if it is deployed on different versions?
On our dev(Windows) machine, we are using JDK.1.4.2_13 and in QA (test) and Prod[Both are UX boxes] its JDK.1.4.2_9.
Am not talking about the major versions, but the minor versions/updates!
I agree its nice if it is consistent across the machines. But is it okay if there is any difference in the minor or updates?
You should not run into any problems with minor version changes, the bytecode format is exactly the same. There are changes between minor versions, but they are generally bug and security fixes, nothing that should affect your application.
That being said, the best option is to run QA and production on the same versions to ensure that there is no functionality changes that will alter how your application works.
There is be no difference in bytecode and APIs in between minor versions. This versions are not the same, of course, but almost all the time, they behave the same way. Some differences can appear though, such as bug that appears an an older JDK and was fixed in a newer one.
Be careful about using right constructs in the heterogenous Win/Unix environment to write once, run everywhere. For example use java.io.File.separator instead of slash or backslash.
As @Nathan recommends, your QA and production environments really must use the same JDK version, and in general be as identical as possible. It's best to have an identical configuration in your development environments too.
For example, say your production environment is at JDK.1.4.2_9, but your development and QA are using the newer JDK.1.4.2_13. Let's also say your new release depends on a bugfix first made in JDK.1.4.2_13. In this scenario, QA will pass, but production will fail, potentially catastrophically.
But your QA is also at JDK.1.4.2_9. Assuming your QA process is good and thorough, it will catch the dependency of your new release on the new JDK.1.4.2_13 and you can fix it.
What if your QA was flawed? In this case the problem would first manifest itself in production. For this reason, its best to keep your development environments on JDK.1.4.2_9 as well, to make it less likely that the error will make it into production.
You can still upgrade to JDK.1.4.2_13 everywhere, just not during a code release. Do this independently, first by upgrading and testing on your development environment, then on the QA environment, and then by deploying the changes to production.
all old version of byte code is supported by new version except deprected apiS BUT NEW byte code is never supported by older versions.
so it is better that according to client requirment or our required methodes alwayes minimum(older) version should be used
See also this SO item about incompatible changes between Java versions.