comparision of classpath and gcj java.io.StreamTokenizer

Sat Jul 22 16:50:00 GMT 2000

Hello
I need java.io.StreamTokenizer for a project, and I noticed that there
are two different implementations in Classpath and GCJ. So I compared
the classes, method by method, to gather the differences. The conclusion
is that GCJ's implementation is better. A complete list of all the
differencies I could find is below.
Nevertheless, some changes could still be done to the GCJ implementation.
I also copied the Classpath doc-comments. This resulted in a 16K
patch, so I didn't attach it. Where should I send it?
Oskar Liljeblad (osk@hem.passagen.se)
---
Comparision between Classpath and gcj java.io.StreamTokenizer
=============================================================
* = patch addresses issue
nextToken gcj is better: gcj uses StringBuffer for token char store,
 cp uses char array of BUFFER_INCREMENT_SIZE.
(char tables) gcj is better looking: gcj uses five boolean tables [256],
 cp uses one [256][5]. cp defines constants WHITE, ALPHA,
 NUMERIC, QUOTE, COMMENT to index this table.
*TT_NONE cp is better: cp has TT_NONE which indicates that no tokens
 has been read yet. (patch adds this type.)
*pushedBack gcj is better: cp has pushedBack true by default to disable
 pushback when nothing has been read. testing shows that
 gcj with patches is closer to Sun's implementation.
lineno gcj is better: gcj has manual (simple) lineNumber counting,
 cp uses LineNumberReader.
*(doc comments) cp is better: gcj lacks doc-comments almost entirely, cp has
 extensive documentation. (patch fixes.)
(coding std) gcj is better looking: gcj follows Sun's method/field naming
 standard, cp has C-like fields with underscore.
*(constructors) cp is better: gcj shouldn't allocate boolean arrays in
 constructor - instead this should be done in each field
 declaration. gcj calls unnecessary resetChar for all chars.
 (patch fixes.)
ordinaryChars, gcj is better: cp throws IllegalArgumentException for chars
commentChar, out of range. tests show that this is not done in Sun's
... implementation. gcjs implementation of these are simpler too.
 These method are synchronized in cp, but they aren't in Sun.
resetSyntax gcj is better: cp catches unnecessary IllegalArgumentException.
pushBack gcj is better: cp stores pushed back tokens, which seems
 unecessary (?). gcj just sets a flag. cp's is synchronized,
 but Sun's isn't.
nextToken gcj is better: shorter implementation, but maybe uses some
 quick optimization hacks. Note that I haven't verified
 the algorithm differences yet.
*toString gcj is better: smaller than cp, but lacks TT_NONE text.
 (patch fixes.)