From commons-dev-return-31757-qmlist-jakarta-archive-commons-dev=nagoya.apache.org@jakarta.apache.org Mon Jun 30 08:01:07 2003 Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 26205 invoked from network); 30 Jun 2003 08:01:06 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 30 Jun 2003 08:01:06 -0000 Received: (qmail 21233 invoked by uid 97); 30 Jun 2003 08:03:42 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@nagoya.betaversion.org Received: (qmail 21226 invoked from network); 30 Jun 2003 08:03:41 -0000 Received: from daedalus.apache.org (HELO apache.org) (208.185.179.12) by nagoya.betaversion.org with SMTP; 30 Jun 2003 08:03:41 -0000 Received: (qmail 23780 invoked by uid 500); 30 Jun 2003 08:00:17 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 23670 invoked from network); 30 Jun 2003 08:00:15 -0000 Received: from post.cnt.ru (212.15.122.243) by daedalus.apache.org with SMTP; 30 Jun 2003 08:00:15 -0000 Received: from ppp3-105.dial-up.cnt.ru (ppp3-105.dial-up.cnt.ru [212.15.120.105]) by post.cnt.ru (8.11.7/8.11.1) with ESMTP id h5U80O828187 for ; Mon, 30 Jun 2003 12:00:24 +0400 Date: Mon, 30 Jun 2003 12:00:57 +0400 From: Anton Tagunov X-Mailer: The Bat! (v1.60h) X-Priority: 3 (Normal) Message-ID: <11011625376.20030630120057@mail.cnt.ru> To: "Jakarta Commons Developers List" Subject: Re: [SURVEY] Commons-URI or not? In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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: commons-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-dev-help@jakarta.apache.org