On 3 Aug 2015, at 16:07, Alexander Stepanov alexander.v.stepa...@oracle.com
wrote:
Please see the updated webrev:
http://cr.openjdk.java.net/~avstepan/8132468/webrev.01/
removed wrapping code/code around the links (mostly PrintStream.java,
PrintWriter.java, File.java), plus other
just in case, the updated webrev:
http://cr.openjdk.java.net/~avstepan/8132877/webrev.01/index.html
On 8/3/2015 4:01 PM, Alexander Stepanov wrote:
P.S. I have also to replace code{@link ...}/code with just {@link
...} in a couple of places here (as in the previous RFR 8132468...)
Regards,
Hello Pavel
Hi Alexander, if I were you I would run specdiff
Thanks; but sorry, I'm afraid I haven't enough time for the extra
experiments just now...
It's very easy to go the all the way and lose oneself in there :)
please accept my condolences :)
Regards,
Alexander
On 8/3/2015 6:33 PM,
Hi Tagir,
Interesting issues.
Regarding Stream.concat, it may be that, today, changes to the
sequential/parallel execution mode aren't propagated to the streams being
concatenated. But is that something inherent to the specification of
concatenation, or is it something that might change in
Hi Alexander,
I think Pavel's advice to run specdiff is useful. It's not too difficult to run
and in this case it provides a useful cross-check for making a large number of
markup changes. Contact me directly if you need help with specdiff. I've run
specdiff over your webrev.01 and I've
Hello, Stuart!
On Tue, Aug 4, 2015 at 5:09 AM, Stuart Marks stuart.ma...@oracle.com
wrote:
Regarding Stream.concat, it may be that, today, changes to the
sequential/parallel execution mode aren't propagated to the streams being
concatenated. But is that something inherent to the specification
Hello!
The PriorityQueue class iterator() returns elements in no particular order.
This is explicitly stated in JavaDoc for iterator() method [1] as well as
in class description [2]. However it's not mentioned mentioned that
spliterator() method also traverses the queue in no particular order.
Hello,
Could you please review the following fix:
http://cr.openjdk.java.net/~avstepan/8132468/webrev.00/
for
https://bugs.openjdk.java.net/browse/JDK-8132468
Just some cleanup for docs (replacing obsolete tt/tt).
Thanks,
Alexander
Hello,
Could you please review the following fix:
http://cr.openjdk.java.net/~avstepan/8132877/webrev.00/
for
https://bugs.openjdk.java.net/browse/JDK-8132877
Just some cleanup for docs (replacing obsolete tt/tt).
Thanks,
Alexander
Please see the updated webrev:
http://cr.openjdk.java.net/~avstepan/8132468/webrev.01/
removed wrapping code/code around the links (mostly
PrintStream.java, PrintWriter.java, File.java), plus other changes in
File.java
Thanks,
Alexander
On 8/3/2015 3:40 PM, Alexander Stepanov wrote:
Hello
Michael, thanks for reviewing!
Vladimir, could you take a look, please?
-Konstantin
On 08/02/2015 05:31 PM, Michael Haupt wrote:
Hi Konstantin,
Am 31.07.2015 um 18:37 schrieb Konstantin Shefov
konstantin.she...@oracle.com mailto:konstantin.she...@oracle.com:
Please review a test
I'm surprised tt is going away. Do you have a reference that explains
the new jdk9 javadoc standards?
On Mon, Aug 3, 2015 at 2:43 AM, Alexander Stepanov
alexander.v.stepa...@oracle.com wrote:
Hello,
Could you please review the following fix:
Looks reasonable to me.
-Brent
On 7/28/15 9:14 AM, Steve Drach wrote:
Please review the following simple fix for the issue reported in
https://bugs.openjdk.java.net/browse/JDK-8062849
https://bugs.openjdk.java.net/browse/JDK-8062849.
-
# HG changeset patch
# User sdrach
#
Bhavesh, it would be good if jep 224 said what to do with the many legacy
tt tags. Best practice seems to be to convert to {@code ...} if possible
and appropriate, else to code, kbd, or samp, as given by
http://www.w3schools.com/tags/tag_code.asp
On Mon, Aug 3, 2015 at 10:21 AM, Alexander
Thanks!
On 8/3/2015 3:53 PM, Lance Andersen wrote:
I think this looks ok also.
I agree with Daniel that we have additional clean-up opportunities
throughout we can do to the javadocs, but keeping each change set
more narrow helps reduce the chance of introducing additional errors
Best
P.S. I have also to replace code{@link ...}/code with just {@link
...} in a couple of places here (as in the previous RFR 8132468...)
Regards,
Alexander
On 8/3/2015 3:57 PM, Alexander Stepanov wrote:
Thanks!
On 8/3/2015 3:53 PM, Lance Andersen wrote:
I think this looks ok also.
I agree
I think this looks ok also.
I agree with Daniel that we have additional clean-up opportunities throughout
we can do to the javadocs, but keeping each change set more narrow helps
reduce the chance of introducing additional errors
Best
Lance
On Aug 3, 2015, at 5:43 AM, Alexander Stepanov
Hello Daniel,
Thank you for the notes;
The code/code is not needed around {@link } - as that should be
the default formatting for {@link }
Sorry, didn't know; I have to fix that.
Would that be easier to read as:
Yes, probably that's better. Some old-style code/code tags were
saved just
On 03/08/15 11:31, Alexander Stepanov wrote:
Hello,
Could you please review the following fix:
http://cr.openjdk.java.net/~avstepan/8132468/webrev.00/
for
https://bugs.openjdk.java.net/browse/JDK-8132468
Just some cleanup for docs (replacing obsolete tt/tt).
Thanks,
Alexander
Hi Alexander,
New JEP Candidate: http://openjdk.java.net/jeps/259
- Mark
On Jul 31, 2015, at 9:23 AM, Peter Levart peter.lev...@gmail.com wrote:
This looks good now. Thanks for taking both of the issues together. I wonder
if a similar racy test could be devised for the 2nd race. I doubt the
ReferenceEnqueue test was meant to catch invalid races specifically. It
On Jul 30, 2015, at 10:22 PM, David Holmes david.hol...@oracle.com wrote:
Looks good!
On Jul 31, 2015, at 5:10 AM, Daniel Fuchs daniel.fu...@oracle.com wrote:
Thanks for taking care of this one!
PS: you might want to add @bug 8132306 to
jdk/test/java/lang/ref/ReferenceEnqueue.java
23 matches
Mail list logo
