2

I have been using java for long time but this question came to my mind recently and has been troubling me since.

I am aware about some conditions where platform agnosticism may be affected in java world via.

  1. code for interaction with file system
  2. using platform dependent libraries in the code.
  3. Also floating point numbers

Are there any more cases where java platform agnosticism may fail? Say a case where my file compiled on Solaris may fail to run on RedHat Linux.

Any help on the topic is appreciated.

Dennis Meng
  • 5,109
  • 14
  • 33
  • 36
Harshdeep
  • 5,614
  • 10
  • 37
  • 45
  • AFAIK, the code for interaction with the filesystem in Java is platform independent. There are system properties for path delimiters, etc. And when you use it, you do not need to worry about platform differences. –  Sep 07 '12 at 14:24
  • @RafaelOsipov: Yes standard coding ways are available to avoid every platform-agnosticism case including interaction with FileSystem but it is a candidate for breaking your code due to introduction of some platform dependent implementation. – Harshdeep Sep 07 '12 at 14:27

3 Answers3

2

Platform specific methods such as

  • Runtime.exec() is platform specific.
  • Anything under sun.* or com.sun.* may or may not be there, or do the same thing.
  • Some system properties are supposed to differ based on the system. e.g. There was one application which expected certain vendors which failed when the VM Vendor changed to Oracle. ;)
  • Anything which depends on System.getenv()
  • using native libraries
Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • Thanks for pointing out `Runtime.exec()`. I am aware about the same but can you please tell what falls under the purview of `sun.*` and `com.sun.*` And also recent oracle security glitch had anything to do with com.sun.* so was it also platform specific? I don't think so! – Harshdeep Sep 07 '12 at 14:24
  • For one vendor and version sun.* will be the same across platforms but different OSes have different vendors and different versions are available. – Peter Lawrey Sep 07 '12 at 14:25
  • What exactly do you mean by 'expect certain vendors'. How does an application expect a certain vendor. Sorry but I am not able to grasp this point. – Harshdeep Sep 07 '12 at 14:35
  • They look up the vendor in a list and if it not one of the ones expected it failed. It was getting the vendor from the `java.exe` – Peter Lawrey Sep 07 '12 at 14:41
  • Different VM vendors are available for java as a language!! I was not aware about this. – Harshdeep Sep 07 '12 at 14:48
1

You need to be careful with paths, e.g. using \ and / between Windows and UNIX is asking for trouble. Also, newline may be tricky: Windows is CR+LF, UNIX just CR (if I recall correctly). Java does provide mechanisms to handle such issues, but naive/new developers may miss them.

Also, I believe OS file locking is different, e.g. on Windows you may be blocked/denied access for something which on UNIX you wouldn't be.

Brian
  • 6,391
  • 3
  • 33
  • 49
  • Forward slashed work fine on Linux/Unix/Windows in the JVM. The only time it might matter is if you're sharing a path with another application that is poorly coded; many programs on windows grok forward slashes as well - some do not. Use java.io.File object to produce native looking paths. Also on Linux/Unix/Windows, Java can handle either form of newline combos just fine. The issue is similar to backslashes. – BillRobertson42 Sep 07 '12 at 14:44
  • 1
    And of course don't forget that Linux/Unix is case sensitive in paths and Windows isn't – NickDK Sep 07 '12 at 14:59
1

Some libraries, which are not platform dependent, use JVM defaults. For example JVM may choose a different cryptography algorithm if you request AES on two machines. In this case you should be more specific when choosing the algorithm, for instance AES/ECB/PKCS5Padding. See Java default Crypto/AES behavior.

So in general, be careful when docs says that there is some default and don't use defaults.

Jarekczek
  • 7,456
  • 3
  • 46
  • 66