Re: RFR of JDK-8158881: Doc typo in src/../java/net/URI.java
On 2016/6/8 4:27, Bradford Wetmore wrote:
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.
Thank you Brad.
Sure, your suggestion sounds reasonable, I should have made it more
clear that the changed URLs in doc are not valid URLs, they just sample.
Please check webrev: http://cr.openjdk.java.net/~mli/8158881/webrev.01/
Thank you
-Hamlin
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 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.javaTue Jun 07
10:33:38 2016 +0800
+++ b/src/java.base/share/classes/java/net/URI.javaMon Jun 06
21:47:44 2016 -0700
@@ -183,7 +183,7 @@
* (1)
*
*
- * 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
*
*
@@ -193,13 +193,13 @@
* Resolving the relative URI
*
*
- * {@code
../../../demo/jfc/SwingSet2/src/SwingSet2.java}(2)
+ * {@code
../../demo/jfc/SwingSet2/src/SwingSet2.java}(2)
*
*
* against this result yields, in turn,
*
*
- * {@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}
*
*
JDK 9 RFR of JDK-8159012: Problem list sun/net/www/http/ChunkedOutputStream/checkError.java
sun/net/www/http/ChunkedOutputStream/checkError.java This test failed intermittently (JDK-8041924), and recently observed failing with high frequency. Please review this patch to put the test to problem list until JDK-8041924 is addressed. bug: https://bugs.openjdk.java.net/browse/JDK-8159012 webrev: http://cr.openjdk.java.net/~amlu/8159012/webrev.00/ Thanks, Amy --- old/test/ProblemList.txt2016-06-08 08:34:32.0 +0800 +++ new/test/ProblemList.txt2016-06-08 08:34:32.0 +0800 @@ -167,6 +167,8 @@ java/net/DatagramSocket/SendDatagramToBadAddress.java 7143960 macosx-all +sun/net/www/http/ChunkedOutputStream/checkError.java8041924 linux-all + # jdk_nio
Re: RFR of JDK-8158881: Doc typo in src/../java/net/URI.java
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 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.javaTue Jun 07 10:33:38 2016
+0800
+++ b/src/java.base/share/classes/java/net/URI.javaMon Jun 06 21:47:44 2016
-0700
@@ -183,7 +183,7 @@
* (1)
*
*
- * 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
*
*
@@ -193,13 +193,13 @@
* Resolving the relative URI
*
*
- * {@code
../../../demo/jfc/SwingSet2/src/SwingSet2.java}(2)
+ * {@code
../../demo/jfc/SwingSet2/src/SwingSet2.java}(2)
*
*
* against this result yields, in turn,
*
*
- * {@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}
*
*
Re: RFR JDK-8156693: Improve usability of CompletableFuture use in WebSocket API
Hi Pavel,
Looks fine.
WebSocket.java:
- line 82: I'd replace 'never' with 'does not'; it is more like a
statement for fact and less a guarantee.
- LIne 54: The notation "{@code .onX}" seems unnecessary, is quite
cryptic, and can be removed.
Are there any tests that would be updated to go along with the change to
CF.
Regards, Roger
On 6/7/2016 11:48 AM, Pavel Rappo wrote:
Hi,
Could you please review the following change for JDK-8156693?
http://cr.openjdk.java.net/~prappo/8156693/webrev.01/
This change addresses some WebSocket API refinements and enhancements from [1].
WebSocket returns `CompletableFuture` from some of its methods. CFs are used by
an implementation to signal when the operation has completed.
Currently, there is a number of known issues with how it's done. These issues
reduce usability of the feature.
1. Change methods that return `CompletableFuture` to return
`CompletableFuture`.
The design was based on a false assumption that `WebSocket` (possibly needed to
continue asynchronous operation) is always accessible in the same scope where
the returned CF is used.
Before:
CompletableFuture wsf = webSocketBuilder.buildAsync();
wsf.thenCompose(ws -> ws.sendText("Hi ", false))
.thenCompose((v) -> wsf.join().sendText("there", false)).join();
After:
CompletableFuture wsf = webSocketBuilder.buildAsync();
wsf.thenCompose(ws -> ws.sendText("Hi ", false))
.thenCompose(ws -> ws.sendText("there", false)).join();
2. Remove stipulation that `CompletableFuture` is returned immediately.
This is needlessly restrictive for an implementation. It might also give a false
impression that the method *always* dispatches to another thread and returns
immediately.
3. Make methods that return `CompletableFuture` to relay (as mush as possible)
recoverable or non-programming exceptions through returned CF.
There's some evidence [2], [3] that this aspect actually makes it harder to use
such methods in completely async computations.
Thanks,
-Pavel
[1] https://bugs.openjdk.java.net/browse/JDK-8155621
[2] http://mail.openjdk.java.net/pipermail/net-dev/2016-April/009638.html
[3] http://cs.oswego.edu/pipermail/concurrency-interest/2016-May/015125.html
RFR JDK-8156693: Improve usability of CompletableFuture use in WebSocket API
Hi,
Could you please review the following change for JDK-8156693?
http://cr.openjdk.java.net/~prappo/8156693/webrev.01/
This change addresses some WebSocket API refinements and enhancements from [1].
WebSocket returns `CompletableFuture` from some of its methods. CFs are used by
an implementation to signal when the operation has completed.
Currently, there is a number of known issues with how it's done. These issues
reduce usability of the feature.
1. Change methods that return `CompletableFuture` to return
`CompletableFuture`.
The design was based on a false assumption that `WebSocket` (possibly needed to
continue asynchronous operation) is always accessible in the same scope where
the returned CF is used.
Before:
CompletableFuture wsf = webSocketBuilder.buildAsync();
wsf.thenCompose(ws -> ws.sendText("Hi ", false))
.thenCompose((v) -> wsf.join().sendText("there", false)).join();
After:
CompletableFuture wsf = webSocketBuilder.buildAsync();
wsf.thenCompose(ws -> ws.sendText("Hi ", false))
.thenCompose(ws -> ws.sendText("there", false)).join();
2. Remove stipulation that `CompletableFuture` is returned immediately.
This is needlessly restrictive for an implementation. It might also give a false
impression that the method *always* dispatches to another thread and returns
immediately.
3. Make methods that return `CompletableFuture` to relay (as mush as possible)
recoverable or non-programming exceptions through returned CF.
There's some evidence [2], [3] that this aspect actually makes it harder to use
such methods in completely async computations.
Thanks,
-Pavel
[1] https://bugs.openjdk.java.net/browse/JDK-8155621
[2] http://mail.openjdk.java.net/pipermail/net-dev/2016-April/009638.html
[3] http://cs.oswego.edu/pipermail/concurrency-interest/2016-May/015125.html
Re: RFR of JDK-8158881: Doc typo in src/../java/net/URI.java
On 2016/6/7 17:34, Chris Hegarty wrote:
On 7 Jun 2016, at 05:50, Hamlin Li 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.
Thank you Chris for taking a look.
What about the scheme, shouldn’t that be updated to ‘https' too ?
Not sure if I understand you correctly, please correct me otherwise.
It's not necessary to update to "https", because it's only sample code,
and it also works well with "http".
Thank you
-Hamlin
-Chris.
Thank you
-Hamlin
--- a/src/java.base/share/classes/java/net/URI.javaTue Jun 07 10:33:38 2016
+0800
+++ b/src/java.base/share/classes/java/net/URI.javaMon Jun 06 21:47:44 2016
-0700
@@ -183,7 +183,7 @@
* (1)
*
*
- * 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
*
*
@@ -193,13 +193,13 @@
* Resolving the relative URI
*
*
- * {@code
../../../demo/jfc/SwingSet2/src/SwingSet2.java}(2)
+ * {@code
../../demo/jfc/SwingSet2/src/SwingSet2.java}(2)
*
*
* against this result yields, in turn,
*
*
- * {@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}
*
*
Re: RFR of JDK-8158881: Doc typo in src/../java/net/URI.java
> On 7 Jun 2016, at 05:50, Hamlin Li 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.javaTue Jun 07 10:33:38
> 2016 +0800
> +++ b/src/java.base/share/classes/java/net/URI.javaMon Jun 06 21:47:44
> 2016 -0700
> @@ -183,7 +183,7 @@
> * (1)
> *
> *
> - * 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
> *
> *
> @@ -193,13 +193,13 @@
> * Resolving the relative URI
> *
> *
> - * {@code
> ../../../demo/jfc/SwingSet2/src/SwingSet2.java}(2)
> + * {@code
> ../../demo/jfc/SwingSet2/src/SwingSet2.java}(2)
> *
> *
> * against this result yields, in turn,
> *
> *
> - * {@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}
> *
> *
>
