This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Patch: FYI: updated expected diffs
- From: Tom Tromey <tromey at redhat dot com>
- To: Gcc Patch List <gcc-patches at gcc dot gnu dot org>
- Cc: Java Patch List <java-patches at gcc dot gnu dot org>
- Date: 27 Sep 2004 14:35:23 -0600
- Subject: Patch: FYI: updated expected diffs
- Reply-to: tromey at redhat dot com
java.net.URL purposely differs from Classpath.
I'm checking this in to inform the nightly comparison machinery.
Tom
Index: ChangeLog
from Tom Tromey <tromey@redhat.com>
* expected/java.net.URL.diff: New file.
Index: expected/java.net.URL.diff
===================================================================
RCS file: expected/java.net.URL.diff
diff -N expected/java.net.URL.diff
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ expected/java.net.URL.diff 27 Sep 2004 20:37:11 -0000
@@ -0,0 +1,27 @@
+--- /home/tromey/gnu/Nightly/classpath/classpath/java/net/URL.java 2004-09-24 02:31:49.000000000 -0600
++++ java/net/URL.java 2004-09-24 02:16:14.000000000 -0600
+@@ -856,6 +856,24 @@
+ {
+ ph = factory.createURLStreamHandler(protocol);
+ }
++ else if (protocol.equals("core"))
++ {
++ ph = new gnu.java.net.protocol.core.Handler();
++ }
++ else if (protocol.equals("file"))
++ {
++ // This is an interesting case. It's tempting to think that we
++ // could call Class.forName ("gnu.java.net.protocol.file.Handler") to
++ // get the appropriate class. Unfortunately, if we do that the
++ // program will never terminate, because getURLStreamHandler is
++ // eventually called by Class.forName.
++ //
++ // Treating "file" as a special case is the minimum that will
++ // fix this problem. If other protocols are required in a
++ // statically linked application they will need to be handled in
++ // the same way as "file".
++ ph = new gnu.java.net.protocol.file.Handler();
++ }
+
+ // Non-default factory may have returned null or a factory wasn't set.
+ // Use the default search algorithm to find a handler for this protocol.