> Well, the memory problem could also be solved by removing the buffers
> (bufferB byte[128] and bufferC char[128]) from Encoding_OneByte.
>
> None of the classes in the hierarchy have a constructor, so the only
> overhead is standard object creation. So the question is if
> Concurrent.synchronizedMap's get() is more expensive than creation. Since
> there is no difference between the objects, there is no need to
> synchronize the whole function. If N threads all race to create a Cp1252
> object, it matters not a bit which one ultimately puts in in the Map.
> Heck, then you could use Class.forName to create the encoder, and no one
> would need to maintain that huge switch statement.
>
> BTW, I don't have CVS access, I was using Koders.com to look at the code.

You can always use the viewcvs service from SourceForge.net:


See the comment to the version 1.10 - "removed encoder caching as it leads
to stream corruption". The reason for this is the way bufferB and bufferC
are used - they are used to keep intermediate results of computation. This
prevents caching of encoders, since each object has a state. I think this
can be improved, but did not check further yet.

If someone comes with a patch that solves this problem in an efficient
manner - I will be more than grateful for the fix.

Roman