Re: java.lang.Character

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Eric" == Eric Blake <ebb9@email.byu.edu> writes:

Eric> The Classpath implementation DOES have the algorithmic
Eric> advantages: it is fully compliant with the 1.4 specs (gcj is
Eric> currently broken in several methods, such as isJavaLetter()),
Eric> and its concept of a direct 2-level fixed-block-size lookup is
Eric> better than gcj's binary search (maximum 10 comparisons for
Eric> Unicode 3.0) followed by a 1-level variable-block-size lookup.
Eric> Besides, Classpath has Javadoc, which gcj lacks.

All nice features, plus which merging has its own inherent benefits in
terms of future changes.  As you can see this little piece of code has
a lot of subtle parts; changing it is probably a bigger task than you
thought you were getting into...  So thanks for doing this.

Our current Character actually has two implementations, depending on
whether you configure for the compact or fast implementation.
However, as you've discovered, it is possible to have a more compact
and yet equally fast (or perhaps faster, depending on caching issues)
implementation.  See also PR 1442.

I don't think it is important to keep the configury option.  Once your
new implementation goes in, let's just delete the code from
configure.in.

Some other things to know:

* The chartables.pl script also generates a java-chardecomp.h file
  which is used by java.text to implement decompositions.
  As I recall this code is fatally buggy -- the native code can read
  past the end of the generated arrays -- but no-one has noticed.

  It would be nice to merge this code with Classpath.  That's pretty
  hairy though.  Unless the new Character has decomposition data in
  it, we must unfortunately keep chartables.pl and modify it not to
  generate chartables.h.

* The Mauve Character tests are probably buggy and could use a
  critical look-over.

Tom