Theory Of Operation

After consideration of how serial communications is achieved in C code some design decisions can be made about the Java code and its associated native functions:

1. The Java package will as far as possible provide methods that wrap the native functions that configure the serial port. It therefore makes sense to create a Serial class whose methods wrap the native functions. In instance of Serial will represent a hardware serial port and it will be possible to have several instances that represent the same hardware serial port in existence at any time. Locking of the serial port's file descriptor will not be provided thus it will be possible to read and/or write to the same hardware serial port from several Serial class instances.
2. The Java package must provide the same flags as used by native functions if only in equivalent in their meaning. The values of such flags do not need to match those of their equivalent native definition but a look-up method must be provided so that native code functions can translate the Java-domain flag value to its native-domain value.
3. The Java package will not be an implementation of the Java Communications API however where possible Java classes and interfaces will be sub-classed and implemented respectively so as to allow the classes within the package to be used as slot-in-replacements for data sources from other hardware e.g. network, rotating disk files.
4. The Java package must not prevent the calling of a native system call that could block. Java code stubs must be provided that will allow the unblocking of a thread without the termination of the whole process. It is not necessary at this stage to implement the code.
5. The Java package should attempt to take advantage of structures provided by the Java language to facilitate the setting of flags and structures required by native system calls. Type-safe techniques should be used whenever possible.