Nevertheless, there are some dependencies that can creep in, such as the directory separator: `/' under Unix, `\' under MSDOS and its derivatives. The ``Pure Java'' initiative tries to discourage hard-coding of such variations, and tries to avoid use of custom-built libraries that exploit such variations.
Despite these attempts, it is impossible to always avoid Operating System dependent code. The whole of the Java Pure program relies on the fact that Sun have written a set of O/S specific libraries that are exempt from sanctions against use. These libraries include all of the O/S specific code to perform networking and windows, for example: the AWT is implemented on top of Motif for Unix, and on top of the MFC for Windows.
So in certain circumstances, it is legitimate to use O/S specific code in Java. Sun encourage use of a standardised set of these APIs in the Java Core libraries. On the other hand, Microsoft have produced a set of extensions that integrate tightly into the Windows world, with COM support, etc. The confusing part of the Microsoft effort is that their extensions are bundled up in their Java products in such a way that it may be difficult to write programs that do not use these extensions.
The Unix systems programmer has no explicit support for their work unless it is supported by the Java Core. This excludes Unix-specific file mechanisms, Unix-specific process and user identification, and so on. The Java support is just not there, forcing the programmer to use languages such as C, tcl, Perl, etc.
This paper describes a set of Java and C files written by the author that implement some of the POSIX system calls in Java. This set is supplied in source form to be built on each Unix platform as a shared library. This can be used for Java applications by setting the CLASSPATH and LD_LIBRARY_PATH to use these Unix-specific Java classes and libraries. They can also be used in applets as long as the shared libraries have been distributed to each target platform.
The POSIX systems calls were not defined for use with an O/O language, but evolved with C. The paper describes the matches/mismatches and some of the choices involved in producing a Java API. Future work may involve a consensus mechanism to resolve some of the choices made.
The work described here does not conform to the Java Pure initiative, and programs using these libraries will not pass the Java Pure tests. Nevertheless, they will allow Unix systems programmers to perform tasks using Java that would have been impossible otherwise. The choice of using these libraries has to be deliberately made by the programmer - it will not be possible to ``accidentally'' fall into use of them.
The current state of the full paper is at http://pandonia.canberra.edu.au/java/unix/paper.html