May I suggest using example.com [1] and an arbitrary path instead on these two examples, so that there's no chance of it being mistaken for a valid URL. This example uses old hostnames that might change yet again (docs.oracle.com) and an ancient JDK platform (1.3), let's just remove that confusion now.

Thanks,

Brad

[1] RFC 2606:  https://tools.ietf.org/html/rfc2606

On 6/7/2016 2:34 AM, Chris Hegarty wrote:

On 7 Jun 2016, at 05:50, Hamlin Li <huaming...@oracle.com> wrote:

Would you please review the following simple doc patch?

bug: https://bugs.openjdk.java.net/browse/JDK-8158881
webrev: http://cr.openjdk.java.net/~mli/8158881/webrev.00/

I’m not sure why the URL’s were ever changed from java.sun.com, since they are 
not
hyperlinks. This was a bad mistake, and badly broke the documentation, for an
unseeingly related change.

What about the scheme, shouldn’t that be updated to ‘https' too ?

-Chris.

Thank you
-Hamlin


--- a/src/java.base/share/classes/java/net/URI.java    Tue Jun 07 10:33:38 2016 
+0800
+++ b/src/java.base/share/classes/java/net/URI.java    Mon Jun 06 21:47:44 2016 
-0700
@@ -183,7 +183,7 @@
 * &nbsp;&nbsp;&nbsp;&nbsp;(1)
 * </blockquote>
 *
- * against the base URI {@code http://java.sun.com/j2se/1.3/} is the result
+ * against the base URI {@code http://docs.oracle.com/javase/1.3/} is the 
result
 * URI
 *
 * <blockquote>
@@ -193,13 +193,13 @@
 * Resolving the relative URI
 *
 * <blockquote>
- * {@code 
../../../demo/jfc/SwingSet2/src/SwingSet2.java}&nbsp;&nbsp;&nbsp;&nbsp;(2)
+ * {@code 
../../demo/jfc/SwingSet2/src/SwingSet2.java}&nbsp;&nbsp;&nbsp;&nbsp;(2)
 * </blockquote>
 *
 * against this result yields, in turn,
 *
 * <blockquote>
- * {@code http://java.sun.com/j2se/1.3/demo/jfc/SwingSet2/src/SwingSet2.java}
+ * {@code http://docs.oracle.com/demo/jfc/SwingSet2/src/SwingSet2.java}
 * </blockquote>
 *


Reply via email to