20

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?

Joachim Sauer
  • 302,674
  • 57
  • 556
  • 614

8 Answers8

31
  • 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
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • 2
    Also: Don't make assumption about path prefixes like \\, C:, / – Peter Štibraný Jan 17 '09 at 18:52
  • 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 Jan 17 '09 at 22:33
  • Don't make assumption about readers reading direction rtl ltr ttb – jpse Oct 24 '11 at 09:20
  • @jpse: That's not so much a *platform* issue as a *UI* issue which could occur on any platform. – Jon Skeet Oct 24 '11 at 09:21
  • @jonSkeet Of course it is in most cases a UI thingy. You may expand it on encoding... make sure to use something like utf-8 – jpse Oct 26 '11 at 13:17
14

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ý
  • 32,463
  • 16
  • 90
  • 116
9

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
  • 91,574
  • 70
  • 187
  • 238
7

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

Joachim Sauer
  • 302,674
  • 57
  • 556
  • 614
6

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

Joachim Sauer
  • 302,674
  • 57
  • 556
  • 614
5

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

Joachim Sauer
  • 302,674
  • 57
  • 556
  • 614
  • 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ý Jan 17 '09 at 17:04
  • But you still limit yourself to all platforms for which you ship the native library instead of all platforms that run Java. – Joachim Sauer Jan 17 '09 at 17:15
  • 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ý Jan 17 '09 at 17:23
1

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

ForYourOwnGood
  • 38,822
  • 5
  • 30
  • 27
1

Off the top of my head...some of these actually happened at work

  • JNI

  • Development tool introduced characters into formatted string literals that worked under Windows but didn't work under Linux (this actually happened)

  • File system inconsistencies (tightly coupling an application to one environment)

  • Underlying hardware such as available memory or cores could result in a change of behavior

gshauger
  • 747
  • 4
  • 16