views:

288

answers:

7

Java is supposed to be "write once, run anywhere" and it really can be, but in some cases it turns into "write once, debug everywhere".

What are the most common reasons for problems when moving a Java application from one platform to another?

What are un-common but interesting reasons?

A: 

There are many different JVMs, so depending on which one the client has installed on their box, they may get slightly different results.

ForYourOwnGood
+7  A: 

I can only speak from personal experience. These are things I've seen:

  1. Threading is abstracted differently on some architectures, so there are slight differences in delays and possibly ordering. (Which could lead to some race conditions)
  2. Controlling the keyboard's statuses (caps lock, num lock, etc) doesn't always work as expected (Linux didn't allow me to change the caps lock to disabled v1.5 at the time)
Allain Lalonde
+17  A: 
  • Don't make assumptions about the case (in)sensitivity of the file system
  • Don't make assumptions about the path or directory separator
  • Don't make assumptions about the line terminator
  • Don't use the default platform encoding unless you're really, really sure you mean to
  • Don't start "cmd.exe" etc (I know, it sounds obvious - but I've seen it cause problems)
Jon Skeet
Also: Don't make assumption about path prefixes like \\, C:, /
Peter Štibraný
I like to raise some noise at our office every now and then about hardcoding /dev/null around the app. Yes, it works nicely as long as you're not running Windows which is supposed to be one of the main platforms we support...
Esko
+2  A: 

Using JNI is something that should be looked into. Providing the native library for every target platform can reduce this problem.

Joachim Sauer
Not if you have libraries for each platform where you want to run your application. At my job I develop an application, which uses external lib via JNI on Windows and Linux. Unfortunately, this library is not available for Mac OS :-(
Peter Štibraný
But you still limit yourself to all platforms for which you ship the native library instead of all platforms that run Java.
Joachim Sauer
Yes, that's right. I just wanted to point out that JNI may not necessarily be a problem. (But it is obviously something to check, so +1).
Peter Štibraný
+6  A: 

Assuming you can write to the directory that contains your applications.

Joachim Sauer
+8  A: 

Few from UI area:

  • Incorrect ordering of buttons like OK/Cancel
  • Using absolute layouts
  • Different accelerator keys
  • Different sizes/rendering of fonts
  • Expecing certain keys to be present (Windows key, Meta key)

(These are not Java specific though)

Peter Štibraný
They may not be Java specific, but it's easy to forget those
Joachim Sauer
+6  A: 

Using classes from the com.sun.* packages that come with the Sun JDK.

Joachim Sauer