Am 19.03.2009 20:02, Xueming Shen schrieb:
Ulf Zibis wrote:
Isn't there any way even to avoid instantiating new ..Array-X-coder
for each invocation of StringCoding.x-code(Charset cs, ...)?
Method x-code(byte/char[]) seems to be threadsafe, if replacement
isn't changed, so I suppose, we could
Ulf Zibis wrote:
:
I'm improving. I've downloaded the tl clone, but I'm disappointed,
because it has 200 MByte, not much less than the complete jdk7. I also
tried nio2 clone, which isn't better, and not updated since 1 year.
(Is there anybody responsible for it's update?)
I would be happy if
Am 25.03.2009 13:07, Alan Bateman schrieb:
Ulf Zibis wrote:
Well, so I should stay on my JRL-persisted
https://java-nio-charset-enhanced.dev.java.net/ for working on my
changes, having an additional HG based NetBeans project to forge
changesets for OpenJDK.
Thank for your help,
-Ulf
If I
Am 21.03.2009 00:02, Xueming Shen schrieb:
to be honest i'm not convinced that a base/abstract-X-coder has any
advantage compared to
current interface approach, at least in this case, can you explain
more? you will have to cast
anyway in the StringCoding class until the those utility methods
Am 20.03.2009 23:17, Xueming Shen schrieb:
Ulf Zibis wrote:
The problem with the dependencies (EUC*, ISO2022*, etc.) from the
jis0201 maps I've solved here:
https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/src/sun/nio/cs/ext/?rev=674
So jis0201 can
