classpath-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [cp-patches] RFC: prevent URL degeneration


From: Robert Schuster
Subject: Re: [cp-patches] RFC: prevent URL degeneration
Date: Mon, 10 Oct 2005 10:08:08 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.7.12) Gecko/20051005

Hi,
@jeroen: I'll look at this later to see why it breaks on Windows.

Until I fix that maybe we could resolve this problem here:
My first patch[0] regarding the URL problem introduced a kludge in aelfred
parser and was rejected by Chris. Now I tackled the source of the problem and
you say that is not ok. Looks like a dilemma ...

Btw: I send Sun a bug report for this, too.

cu
Robert

[0] - http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24249

Jeroen Frijters wrote:
> Robert Schuster wrote:
> 
>>2005-10-07  Robert Schuster  <address@hidden>
>>
>>    * java/net/URLStreamHandler.java:
>>    (toExternalForm): Remove superfluous leading slashes from URL
>>    paths.
> 
> 
> This patch introduces several Mauve regressions for me (on Windows):
> 
> FAIL: gnu.testlet.java.net.URL.URLTest: new URL(string) (number 1)
> FAIL: gnu.testlet.java.net.URL.URLTest: new URL(string) (number 19)
> FAIL: gnu.testlet.java.net.URL.URLTest: new URL(string) (number 31)
> FAIL: gnu.testlet.java.net.URL.URLTest: new URL(string) (number 40)
> FAIL: gnu.testlet.java.net.URL.URLTest: new URL(protocol, host, file)
> (number 29)
> FAIL: gnu.testlet.java.net.URL.URLTest: new URL(protocol, host, file)
> (number 33)
> FAIL: gnu.testlet.java.net.URL.URLTest: new URL(protocol, host, file)
> (number 37)
> FAIL: gnu.testlet.java.net.URL.URLTest: new URL(protocol, host, file)
> (number 41)
> FAIL: gnu.testlet.java.net.URL.URLTest: new URL(protocol, host, file)
> (number 45)
> FAIL: gnu.testlet.java.net.URL.URLTest: new URL(protocol, host, file)
> (number 49)
> FAIL: gnu.testlet.java.net.URL.URLTest: new URL(protocol, host, file)
> (number 53)
> 
> I also disagree with it on principle grounds. We should match the JDK in
> cases like this, not try to do the "right thing". It's very easy to
> break applications that depend on the JDK URL implementation and it is
> not reasonable to expect them to be fixed if the JDK is never going to
> get fixed (which I can assure you, it isn't).
> 
> Regards,
> Jeroen
> 
> 
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]