Re: generation of gnu/java/locale/*.uni

[Eric Blake]

Artur Biesiadowski wrote:
> 
> I know that I tell it every time Character issue comes - but aren't we
> going to use alternative Character posted here some time ago (2 years?).
> It had a LOT better performance (no object creation during check and
> check itself quite faster) , encoded all data in Strings (so there was
> no need to play tricks with loaders and dependency on gnu/something
> class). Only problem I had was, I was unable to compile it with old
> jikes due to some funny unicode.

Hmm, I did find it kind of fishy that the current implementation was
creating so many throwaway objects.  However, while the changes I made
further separate the two implementations, I'll look at incorporating the
benefits I see in the alternative:

1. loading from Strings instead of Java File IO is nicer, making the
static initialization slightly faster, but more importantly less
dependent on other classes (note that I would still be using file IO, as
the data must be in a separate file to be easily upgradeable; but
implicitly through the VM ClassLoader and not explicitly)

2. caching all attributes in arrays requires more runtime memory, but if
the arrays are compressed enough, this is a hands-down win over frequent
object creation

3. character class checks, such as isLetter(), are more efficient, using
a shift and single comparison to a constant instead of a series of
conditional comparisons

> 
> Even if it might be out-of-date and non-compilable today, it might be
> nice to maybe work with it ? Or otherwise tell me that it WON'T be used
> ever, so I can stop touching this subject every time Character is on
> board :)

Thanks for bringing up the issue.  I hope to make some of those
improvements in the near future.

-- 
This signature intentionally left boring.

Eric Blake             address@hidden
  BYU student, free software programmer