Java Implementation


In both our Java and C++ implementations we are going to start building a common library. This is more evident in Java, where building the Java package can be seen in the source code. All that happens in C++ is that we start building a common object library. We'll use net.babelblaster as the prefix for our packages.

The Java implementation is composed of the following source files, which correspond to the base classes described previously. We also add the DOM Validator class we developed in Chapter 5, our standard SAXErrorHandler, a Babel Blaster exception class, and a class for text constants.

  • DataCell.java : in package net.babelblaster. cell

  • Converter.java : in package net.babelblaster.converter

  • SourceConverter.java : in package net.babelblaster.converter

  • TargetConverter.java : in package net.babelblaster.converter

  • RecordHandler.java : in package net.babelblaster.record

  • RecordReader.java : in package net.babelblaster.record

  • RecordWriter.java : in package net.babelblaster.record

  • DOMValidator.java : in package net.babelblaster.utility

  • SAXErrorHandler.java : in package net.babelblaster.utility

  • BlasterException.java : in package net.babelblaster.utility

  • TextConstants.java : in package net.babelblaster.utility

As I said earlier, we're not going to look at the Java or C++ code in detail in the remainder of the book unless there's something really significant to discuss. I do want to note a few things though.

All our data is handled as bytes and byte arrays rather than strings or string buffers. For example, the Cell Buffer in the DataCell class is implemented as a byte array. In addition, all the I/O operations deal with bytes. It might be simpler in some cases to handle these as strings, but this strategy gives us future flexibility for supporting data encodings such as EBCDIC that might not be processed like string data. Some of the derived classes may convert data to strings or string buffers as part of the conversion to or from XML. We'll do this only after we already have the data in a string-compatible format, and the native storage format will remain bytes. One effect of this approach is that as a convenience all our DataCell putField and getField operations have byte array and string versions (the latter is a toString method). In addition to the default constructor we also have versions that allow the field contents to be initialized , passing them either as a byte array or string.

The readRecordVariableLength method in RecordReader is implemented with a BufferedInputStream. The only really awkward part about the code is the fact that the single character read method returns an integer instead of a byte. We have to use the Integer class to convert to a byte before we append the byte to the input record.

Per the previous comments, we're creating a TextConstants class where we'll declare the text commonly used in our programs. Some of the main routines will have unique text corresponding to the particular program, but wherever practical we'll declare the text here.



Using XML with Legacy Business Applications
Using XML with Legacy Business Applications
ISBN: 0321154940
EAN: 2147483647
Year: 2003
Pages: 181

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net