Is Java completely Platform Independent?

Is Java completely Platform Independent ?

if not then, what care needs to be taken to see that your code written in Java can run on Multi Platforms. Basically it should work开发者_如何学Go on Targeted Platforms like Windows (Various versions), Linux (all flavors), Mac and Solaris.

While in practice, most compiled byte code is platform independent, my experience in my 12 years of developing on the Java platform has taught me that there are still idiosyncrasies from platform to platform.

For example, while developing a Java 1.4 Swing application for PC and MacOSX the behavior of dialogs was different if the parent frame is null.

Another example might be with working with the file system and files in general. The Java API has methods to help shield the developer from differences in path separators (/ vs \). When writing to a file, it important to use the FileWriter API as intended so that return characters and such are generated properly for the platform that it is being written on.

So while the motto is "write once, run anywhere" my experience has been for production envs it is write once, test, everywhere.

As a result, having strong unit and integration tests can help with this, as you can execute those tests on the various platforms you want to distribute your software.

Despite some minor issues here and there, it is cool to see your code running on Linux, Unix, Windows and MacOSX (BSD Unix) using the same JARs.

As djacobson pointed out, the answer is a qualified "yes". For the most part, Java developers don't have to worry about platform dependencies. However, you may run into problems when you're dealing with APIs that handle traditional OS and platform functions.

When dealing with File I/O, for example, it's easy to make your code platform dependent by ignoring the differences between file/path separators across platforms (i.e. using '\' rather than File.separator).

For the most part, yes. Because Java compiles to bytecode that's executed by its virtual machine, it can generally be expected to behave the same way regardless of the system sitting under the virtual machine.

However. Not even virtual machines are immune to bugs. A quick Google search turns up the following, for example:

http://www.ibm.com/developerworks/java/library/j-diag0521.html

Differences in behavior can vary from JVM to JVM. Hopefully you won't end up with code that depends on any of these cases... but careful research is worthwhile to know what the limitations of your infrastructure are.

You problem will not be executing your code, but more likely the assumptions you have to make about file paths, available external commands (if you need them), necessary file permissions and other external factors that don't really fall under the "Java" problem domain. Unless you're planning on using native code (via JNI) extensively, Java will not be your problem, your environment will. Which brings us back to the old adage: "write once, test everywhere".

Threading priorities is one thing to consider. Other OS like Solaris for example has more thread priorities than windows. So if you are working heavily on multi-threading, OS is something that may affect the program's behavior.

The main thing to be concerned with is UI code, to make sure that it is represented properly on all the platforms you will be running on.

Another source of possible issues is deploying to different app servers. There might be incompatibility issues between them.

Java other than that is platform independent, This is also one of its weaknesses, since you are coding to a common denominator and many features of each individual OS are not available.

There are very few and they should be pretty obvious. like System.getProperty("os.name") is clearly OS dependant or it wouldn't work. The most common one is System.exec() as it calls another application which is on your system, again you should know if the application you are calling works the same on every system or not (unlikely).

Along with the above concerns, the main problem I had was actually building on different platforms, which may not be what your asking, but may be something to watch out for.

OS X is especially guilty of this when using the Apple Distribution of Java (why anyone would want to put out their own packaging of Java I don't know but that is a separate argument, and on OSX i dont think you have a choice but to use their java). The Libraries that you may or may not be relying on are in completely different directories, eg libraries instead of lib if my memory serves me correctly. And the IBM java I think packages Classes in different Jars in some cases. Ridiculous!!

Hope that helps.