Artur Biesiadowski wrote:
> There is a bug in gnu.java.io.encode/decode classes. It is not apparent
> on first glance, but it is there.
Oops. You are right. This is not good. I will have to fix this.
> It can be fixed in few ways. convertToChars can be copied to each
> subclass and use specific lookup tables instead of just shared
> lookup_table. DecoderEightBitLookup can become non-abstract with
> additional field holding pointer to lookup_table (it will be a small
> performance penalty - statics are generally faster than instance
> variables).
I'm working on something else right now, but I will put some thought into
this soon.
> Small performance update - in convertToChars cbuf_offset and buf_offset
> could be inc'ed directly to save few iadd opcodes.
You are correct again. I will make that change. This stuff is used
constantly and needs to be as fast as possible.
> Note - Encoders use 128kb per encoder. I know that it is simpliest, but
> it is really a lot of memory. I think that some other way should be used
> - for example manual check for <= 127, if not, then binary lookup in
> encode table (which would have to be in form of {char, byte} map). This
> way we find encode in 7 checks in worst case and save a lot of mem.
I actually did that not only because it was simplest, but because I thought
it would be fastest as well. I definitely wanted to try for fast. Memory
was only a secondary concern, but I did want to avoid having each instance
of a class allocate a new table. You are bringing me back to old design
issues I never completely resolved!
Thank you very much for this report. If you have any other comments on the
genernal design of this component, I'd appreciate hearing them as well. Hit
me. I can take the abuse. :-) I think my design is quite different from
Sun's as I did not attempt to reverse engineer what they did.
One of my goals was to make the implementation of encodings useful to
applications directly. (Though I admit I have not thought of a ready
application for it). To this end I made the encoder/decoder subclasses of
Writer/Reader. I also planned to add a facility to allow applications to
query the list of available encodings. And to allow users to easily install
their own translators. Sun's attitude is that sun.* is off limits to
programmers. I don't want to force programmers to take that attitude
towards gnu.java.*. While code that relies on it might not be portable to
all libraries, this could be corrected if the user simply copied the
necessary classes directly into their code, which under the LGPL they are
free to do.
--
Aaron M. Renn ([EMAIL PROTECTED]) http://www.urbanophile.com/arenn/
