Hello Sung-Gu! SG> I suggest that jakarta-commons provides flexible URI issue implementations SG> as a package.
Looking forward to see it appear in jakarta-commons. :-) BTW, do you think that (char[] data, int start, int len) versions of methods should be included? (Something that I'm probably doing in now for myself) A recent test that I have carried out showed that .charAt() is 1.8 - 1.9 times slower then [] on a char array, just in case I attach the test case. This happens because with char[] I believe each char takes two bytes, while with String they have UTF8 and probably have to travel the whole string from the beginning to find charAt(i). It will be true if someone here will say that it will be premature optimization, but if someone is mad enough :) launch a new project for URI-s why not think of this also? Then, it would probably be worth looking into Tomcat internals. I believe they should some code of that kind internally too (they have to parse URI-s). I believe they should be using the char[] versions. Indeed some documentation even on Tomcat 3 said that they have found the .stratsWith() and co functions to be to slow. This means they've found found a way to speed it up. How? I believe they have switched to char[] (don't see other way to speed up). Is this project going to be to ambitious to become a dependency both for HttpClient and for Tomcat? :-)) Anyway, even if it does not become one, it would be good to a code of equal quality in it. WBR, Anton P.S. Just a side-note (the overall ideal of the subproject is very much welcomed :) is there going to be any overlap with the code project in coding/decoding the uri-s? HttpClient have just donated something there.. And there are some EscapeUtils in lang, aren't there? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
