EVALUATION

I am not familiar with the charset code but I run the testcase and go through the source code of this part. Seems to me that this is a right behavior. 
Every time the getBytes run lookupViaProvider() to find the charset but failed every time because eucJP-open charset is not defined in our default charset names. Then the caching is not functioning.  If you change the charset name to euc_jp, the problem will go away.

My understanding is that the customer want to provider their own implementation to use eucJP-open. I add ###@###.### in the interest list. I think he is the original developer for charset provider.


###@###.### 2004-11-19 02:51:56 GMT

While this is the "correct" behavior of Provider lookup mechanism, it's not 
an acceptable performance for the j2se product...

The root cause is we don't have eucjp-open and pck in nio charset 
collection in 1.4.2_xx, there are ctb/btc (We have them now in 1.5,
see bug#4892738). Current implementation of StringCoding class caches 
only one "last used" charset/converter per thread, so using two encoding 
names repeatly easily "penetrates" this cache mechanism, and the worse 
is that the eucjp-open does not exist in any of the StandardCharset
Provider or the ExtendedCharsetProvider, so next levels of cache in
Charset and AbstractCharsetprovider also do not help, we endup of
reaching the final lookup layer to lookup for "new" charset provider again 
and again, which is expensive. The reason we don't see the same issue with 
PCK is that we have a special "if PCK" code in StringCoding.java. We have
the same problem with all encodings that only exist in sun.io package, 
such as those IBMxyz encodings.

2 possible quick/easy solutions for this particular issue would be
(1)Add the same "special" code for eucjp-open in StringCodeing.lookupCharset()
or
(2)backport 4892738 to 1.4.2_0x, which I think is the better approach.

The disadvantage of above 2 solutions is we still have the same issue with
those IBMxyz encodings, if customer care them...

Since this issue does not exist in 1.5 and later. Submitter needs escalate to
CTE to get this one fixed in 1.4.2_08 release.

###@###.### 2004-11-19 05:07:16 GMT