Kevin Zhou wrote:
It looks good! :)
Not so good, it cause test failures. seems most of them are failed in
compareToIgnoreCase and toUpperCase. Would you please take a look at it?
On Mon, Apr 20, 2009 at 1:53 PM, Regis xu.re...@gmail.com wrote:
Regis wrote:
Kevin Zhou wrote:
I found at String:619, it should be
return codePoint - ('a' - 'A');
and at String:595, it should be
return (char) (ch + ('a' - 'A'));
Is it right? And for private char compareValue, could we return directly if it's
ASCII lower case, like:
private char compareValue(char ch) {
if
Nathan Beyer wrote:
On Sat, Apr 18, 2009 at 3:32 PM, Tim Ellison t.p.elli...@gmail.com wrote:
I'm interested too.
I hope that doesn't mean you think my code is getting bad. :)
:-) not at all. I am simply interested to know if there is still a
problem to solve here. I was expecting your
Hello,
Under resource constraints we may even think of dropping Java 5 in favor of
Java 6. This would save Java 6 supporters their merge efforts and nullify
merge bugs.
Why have not we done that before? AFAIK, one wanted to pass TCK for Java 5,
and that was an important step to ship Harmony
Regis wrote:
Tim Ellison wrote:
Regis wrote:
RI has the different behaviors on Linux and Windows in this test case,
and Harmony has the exactly the same behaviors, so I think our
implementation is OK.
And there are some other similar cases in SocketTest, which failed on
Linux but passed on
Alexei Fedotov wrote:
Under resource constraints we may even think of dropping Java 5 in favor of
Java 6. This would save Java 6 supporters their merge efforts and nullify
merge bugs.
Maybe. I hadn't thought of going that far - at least, not without a
reasonable overlap period that allows
Tim Ellison wrote:
Regis wrote:
Tim Ellison wrote:
Regis wrote:
RI has the different behaviors on Linux and Windows in this test case,
and Harmony has the exactly the same behaviors, so I think our
implementation is OK.
And there are some other similar cases in SocketTest, which failed on
Hi, All
I'm trying to run build our source code within JavaSVN[1]
With JavaSVN we can build our code over other platforms in which we
don't have a native Subversion to use.
But It turns out that JavaSVN doesn't support --non-interactive[2]
JavaSVN only support Subversion 1.3.0 right now.
svn
Regis wrote:
The new fix committed at r766631. I'll continue tide-up SocketTest, and
try to move it out from exclude list.
Cool!
On Sat, Apr 18, 2009 at 12:34 PM, Nathan Beyer ndbe...@apache.org wrote:
Can you and anyone else looking to make contributions go through the
contribution policy [1] and get an ICLA/CCLA and an ACQ submitted?
I faxed the paperwork to Apache this morning.
Thanks,
Jesse
Thanks
Sent from my iPhone
On Apr 20, 2009, at 3:11 PM, Jesse Wilson jessewil...@google.com
wrote:
On Sat, Apr 18, 2009 at 12:34 PM, Nathan Beyer ndbe...@apache.org
wrote:
Can you and anyone else looking to make contributions go through the
contribution policy [1] and get an ICLA/CCLA
On Sun, Apr 19, 2009 at 10:39 PM, Regis xu.re...@gmail.com wrote:
Since every time icu update, it behaviors change, and we may need to modify
our delegate code to make Harmony work with it correctly, some test cases
need to update as well.
Is it really that bad? I can understand the upgrade
Kevin,
Can you comment on this question?
On Mon, Apr 20, 2009 at 2:42 AM, Tim Ellison t.p.elli...@gmail.com wrote:
Nathan Beyer wrote:
On Sat, Apr 18, 2009 at 3:32 PM, Tim Ellison t.p.elli...@gmail.com wrote:
I'm interested too.
I hope that doesn't mean you think my code is getting bad. :)
The latest version of SVNKit has beta support for Subversion 1.6.0.
What platform have you run into that doesn't have native Subversion
support? I've never considered that a big issue.
On Mon, Apr 20, 2009 at 4:18 AM, Sean Qiu sean.xx@gmail.com wrote:
Hi, All
I'm trying to run build our
Hi,
Sorry for my delay reply.
Suppose we set up a URL array (e.g. urls) of jars as search patch and use
java.lang.URLClassLoader to find a resource.
If the resource is not found in the given jars, URLClassLoader will try to
find the resource from other jars specified in META-INF/INDEX.LIST of the
Yeah but my change didn't do that correct? I changed a null check so
that a cache was actually being used.
Sent from my iPhone
On Apr 20, 2009, at 9:03 PM, Kevin Zhou zhoukevi...@gmail.com wrote:
Hi,
Sorry for my delay reply.
Suppose we set up a URL array (e.g. urls) of jars as search patch
Before your patch, the check was like:
URLHandler sub = subHandlers.get(url);
if(url != null) {
return sub
}
Apply your patch, the check changes to:
URLHandler sub = subHandlers.get(url);
if(sub != null) {
return sub;
}
Obviously, previously it always return null sub if the url was not
Regis wrote:
Regis wrote:
Tim Ellison wrote:
Regis wrote:
Tim Ellison wrote:
Regis wrote:
RI has the different behaviors on Linux and Windows in this test
case,
and Harmony has the exactly the same behaviors, so I think our
implementation is OK.
And there are some other similar cases in
That's exactly what I was looking for. I just wanted to validate my
understanding of the code that was changed in both of our patches.
Thanks for the info.
-Nathan
On Mon, Apr 20, 2009 at 10:02 PM, Kevin Zhou zhoukevi...@gmail.com wrote:
Before your patch, the check was like:
URLHandler sub =
:)
On Tue, Apr 21, 2009 at 12:45 PM, Nathan Beyer ndbe...@apache.org wrote:
That's exactly what I was looking for. I just wanted to validate my
understanding of the code that was changed in both of our patches.
Thanks for the info.
-Nathan
On Mon, Apr 20, 2009 at 10:02 PM, Kevin Zhou
20 matches
Mail list logo
