< Zurück | Inhalt | Weiter >

4.5.2 Portability

Be aware that the more environment-specific code you build, the less portable your application becomes. It’s not uncommon to use a properties file as a way to parameterize your program, to customize its behavior in a given installation. But keep these to a minimum to stay portable. Avoid invoking other programs, they are likely not available in all environments where Java can run. Java’s claim to “compile once, run anywhere” is amazingly true—provided you keep away from logic in your program that goes looking for trouble.


Java command-line parameters are not that different from C/C++ command- line parameters. Environment variables are a different story. Most of the shell’s environment variables are not readily accessible, and we looked at how you might deal with this situation.

We have discussed, among other things, some uses for these classes: java.util.Properties, java.lang.System, and java.lang.Runtime, but we have only barely scratched the surface. There are many more methods available in these classes with which you can do lots more.


The biggest topic in this area that we’ve avoided for now is the Java Native In- terface (JNI), a mechanism whereby you can get outside of the Java environ- ment to make calls to existing (native) libraries—for example, Linux system calls. In a coming chapter we’ll actually give you an example of such a call.

Then you’ll really be able to make your application nonportable and system-dependent. (But sometimes portability isn’t your goal, right?)


Perhaps the best resource for the specifics that you’ll need to work with the topics mentioned in this chapter is the Javadoc documentation on the classes that we have mentioned. Learn to read Javadoc pages (see Section, bookmark them in your browser, and keep them handy as you write your Java code.